Community
Participate
Working Groups
This is related to bug 25208, but not quite the same. There seems to be some inconsistency between the working set API's and the actual implementation. If I create my own instance of a IWorkingSet and add it to the platform working sets: PlatformUI.getWorkbench().getWorkingSetManager().addWorkingSet(myWorkingSet), then there are places in the UI code that assume that working set instances are of type org.eclipse.ui.internal.WorkingSet, in particular code that deals with the getPageId(). Is it possible to make getPageId() (or something similar) an API on IWorkingSet ?
This assumption is valid since clients are not supposed to implement IWorkingSet. You should only create them using IWorkingSetManager.createWorkingSet. Bug 25208 is requesting to expose the edit page as API and I plan to do so. Is there other functionality you are missing that requires you to implement IWorkingSet?
I think that if the pageID is exposed as an API than could be sufficient. Anyway, here is a brief description of the problem that I am facing: We need to support working sets in the help system, to be able to define documentation search filters. The help view is done entirely in HTML/Javascript, including the search function and the ability to add/remove/edit working sets, essentially a similar pattern to that in the workbench. The constraint for help is that, it must also work in a "headless" eclipse. So, all the code to deal with help specific working sets is done in a non-UI dependent fashion. Now, a workbench aware help plugin is contributing a help search page to the workbench. There we want to also support working sets, so we want to plug in the working set suppport that's part of the workbench. The problem comes when we want to ensure that working sets created in either the workbench or the help view are visible and can be manipulated in both the workbench *and* the HTML help view. The solution must involve the working set property change listeners, with a listener class sitting in our help UI plugin (which is different than the plugin defining the html help view)that keeps the help working sets in the workbench in synch with those in the "headless" help working sets. Ideally, the best solution is to have most of the working set stuff moved in the non-UI plugins, just like we did with plugin preferences in the past.
I think I also need to have the IPersistable and IMemento interfaces in the core platform.
It is not clear what the proper location would be of the basic working set support if it didn't live in platform ui. Changing the title to reflect the actual request. As per bug 25208 I'll make setPageId API.
Maybe the org.eclipse.core.resources is a good place.
Unfortunately not, since working sets are resource independent.
That's true. For now, we have a solution in help, it is not nice (have to duplicate some of the functionality provided by the ui plugins), but at least it seems to work. When it doesn't, I'll re-open the bug :-)
OK, this has not happen in 2.1, but may be there is a chance to revisit this for the 3.0 release. 2.1 help shipped with duplicated WorkingSetManagers, and complicated synchronization mechanisms, that Dorian suprisingly got to work on time for 2.1, but we have not enabled help working sets for Infocenter scenario. For 3.0 we need to enable help working sets in the infocenter, and ask again for WorkingSet support move to non UI plug-in. Help code that deals with working sets is already too complicated and fragile. If resouces and runtime are not appropriate places, than a new non ui plugin should be created for working sets. There has been another bug 29555 opened, asking for core support for IWorkingSet.
There are no immediate plans to move working set support down to Core. John summarizes some additional issues in bug 29555: "...if it's generic enough to go into core, then it's no longer useful enough for clients in the UI and JDT. Some users wanted static sets like IWorkingSet, others wanted rule-based sets like JDT, some needed change notification, some wanted serialization and some didn't, etc..."
The following is a discussion with the help team about their working set use cases. Most recent note at the top. " Knut Radloff@IBMUS 05/21/2003 05:03 PM To: Konrad Kolosowski/Toronto/IBM@IBMCA cc: Dorian Birsan/Toronto/IBM@IBMCA, Nick Edgar/Ottawa/IBM@IBMCA, John Arthorne/Ottawa/IBM@IBMCA From: Knut Radloff/Raleigh/IBM@IBMUS Subject: Re: Core vs. UI working sets (bug 27519) I talked to Nick about this and explained your use cases and concerns. The bottom line is that we don't want to change how the working set support is factored at this point. We understand that your working around the UI dependency is undesirable. However, this is not a priority item given that we have many other plan items that will benefit other teams and products. We also would not want to rush and create new plugins for the new Core components. We can revisit Core working set support if it becomes a priority for more teams and when we get more use cases for headless working sets. In the meantime I will move the bug to platform-ui-inbox and mark it a P4. Knut Konrad Kolosowski@IBMCA 05/20/2003 05:24 PM To: Knut Radloff/Raleigh/IBM@IBMUS cc: Dorian Birsan/Toronto/IBM@IBMCA From: Konrad Kolosowski/Toronto/IBM@IBMCA Subject: Re: Core vs. UI working sets (bug 27519) Knutt, If working sets were core we would not have to deal with wrappers, additional layer of adaptables and this kind of tricks. All pieces of help system could use same interfaces and pass working sets freely. The only extra code, that is infocenter specific (storing infocenter working set in cookies) would be in the webapp, the rest of help would be cleaner. [deleted discussion about how to select search scopes in help browser] Synchronization code is the extra complication that we would like to eliminate. If you look outside of help, any tool can make use of working sets and not require UI. It makes some sense to have a build that rebuilds all projects in my working set, for example. Placing working set by accident in UI is not the right way, I think. If both help and UI need to use working sets, help cannot require UI, it is pretty obvious that the support needs to be at the lower level. Do not you agree? Konrad Kolosowski Eclipse Help System Knut Radloff@IBMUS 05/20/2003 04:34 PM To: Konrad Kolosowski/Toronto/IBM@IBMCA cc: Dorian Birsan/Toronto/IBM@IBMCA From: Knut Radloff/Raleigh/IBM@IBMUS Subject: Re: Core vs. UI working sets (bug 27519) For scenario 4 you could still use core working sets, you would just have to persist them yourself in a web browser compatible way (e.g., cookies, like you do now). They just wouldn't buy you much. [deleted discussion about how to select search scopes in help browser] So basically you want to avoid the synchronization, besides the duplicated code. Knut Konrad Kolosowski@IBMCA 05/20/2003 03:57 PM To: Knut Radloff/Raleigh/IBM@IBMUS cc: Dorian Birsan/Toronto/IBM@IBMCA From: Konrad Kolosowski/Toronto/IBM@IBMCA Subject: Re: Core vs. UI working sets (bug 27519) Knut, There is 4 search scenarios: 1. Workbench launched, search dialog opened. 2. Workbench launched, scope dialog from help browser opened. 3. Stand-alone help launched (UI plug-in's might or might not be present), scope dialog from help browser opened. 4. Infocenter running on a server (UI plug-in's might or might not be present), scope dialog from browser opened on users' machines. When you run Eclipse the usual way, you can search help as in 1 or 2 (launch help, click on search scope to define working sets). 1 and 2 need to be synchronized at all times. Both UIs allow viewing, creating, editing working sets and using them (performing search, passing working set to search back end). Neither webapp UI nor help system can depend on the UI plug-ins or even assume their existence, due to need to support 3 and 4. Scenario 3 has one user only. The way help browser is launched might be different from Workbench scenario, and there is no UI plug-ins but working sets must work exactly as in 2. Scenario 4 is has multiple users. It is similar to scenario 3. The code has been released in Eclipse 3.0 to support this scenario with working sets being persisted in cookies only. These working sets are not synchronized with ones stored locally in the workbench. As you see there is only a slight variation from each scenario to the next. We do not have separate help code for each scenario (we could not contain the work). The help back end that performs search and filtering uses (help implementation) of working set in all scenarios. Having a need to support scenario 1, requires that we use working sets that are in UI. We need to make sure they are supported, but we cannot depend on them in any way. It adds and not reduces our code in any way. The synchronization part is the most convoluted. User might work with working sets from webapp only, without touching help UI plug-in or with vice versa, or they can use both plug-ins to be loaded. Synchronization between UI working sets and help working sets needs to occur when plug-ins load, on demand pieces of the system load, and also have listeners registered to react to changes to working sets that happen after initial loading. For infocenter (4) I am not looking to use working sets implementation from the workbench. Obviously the implementation must be different. Hoverer the help code to support 1, 2, and 3 is already more complicated that I would like to see or that is easy to follow. With working sets existing in UI, we cannot even use interfaces, and we have to custom clone working sets when synchronizing. The new code that I released into 3.0 for scenario 4 seems to be working. I say "seems" because overall system is too complicated, and chance for bugs is high. At the end (with some more testing) it will work as 2.0 worked, but I am really, really looking forward to being able to clean it up with working set moved down from the workbench UI. Konrad Kolosowski Eclipse Help System Knut Radloff@IBMUS 05/20/2003 09:48 AM To: Dorian Birsan/Toronto/IBM@IBMCA cc: Konrad Kolosowski/Toronto/IBM@IBMCA From: Knut Radloff/Raleigh/IBM@IBMUS Subject: Core vs. UI working sets (bug 27519) I'd like to better understand your working set use cases. You currently implement your own/copied working set support for standalone help. In addition, you want the user to be able to create help working sets using the regular working set UI when searching help within the workbench. You don't want to synchronize the two implementations. Is this correct so far? I don't understand the Infocenter scenario. Would the help working sets be stored on the server? Why can't you use your own working set implementation for this? Or is it that you just want to get rid of the synchronization code? Also, how do I use working sets in standalone help? I didn't see any way to search working sets other than using the workbench search. Knut"
WorkingSets were reworked in 3.2.
*** Bug 270118 has been marked as a duplicate of this bug. ***
*** Bug 351741 has been marked as a duplicate of this bug. ***
