Community
Participate
Working Groups
build I20050315 From bug 83658 comment 17: An unfortunate side-effect of this split is that it is technically hard to have more than one type of WorkbenchWindowAdvisor - but the APIs make this seem possible. The WorkbenchAdvisor needs information about which type of WindowAdvisor to create and currently it doesn't have access to either the page input or perspective id when createWorkbenchWindowAdvisor() is called. From bug 83658 comment 18: > it doesn't have access to either the page input or perspective id when createWorkbenchWindowAdvisor() is called I'm aware of this limitation, and am planning on making this info available, either to the create method directly, or via get methods on the IWorkbenchWindowConfigurer. Any preference? From bug 83658 comment 19: Advantage of method parameters are that they are explicit but the advisor will have to cache them if they are needed later. If they are available via the configurer they are automatically cached. I don't have a strong preference. From bug 83658 comment 20: > it doesn't have access to either the page input or perspective id when createWorkbenchWindowAdvisor() is called It turns out this is harder to handle than I thought. The page input and perspective ID are available and can be passed when the window is first opened, however when a window is restored from a previous session, this info is not available before the window is created (and is no longer considered an argument to the window creation). I'm going to have to leave this for 3.2.
+1 from me. It looks like we need something like this: 1) The ability to declare a specific 'workbench window type' 2) The ability to declare a workbench window advisor for the type 3) The ability to pass the window type to IWorkbench.openWindow() methods. 4) The ability to hide the perspective from 'Open Perspective' window 1) and 2) can be handled through an extension point (or by adding additional elements to an existing extension point). The assumption is that the functionality is required by a plug-in that has no control over the workbench advisor. 3) We can add additional method to IWorkbench: openWorkbenchWindow(String windowTypeId, String perspectiveId, IAdaptable input) throws WorkbenchException; This should be possible because IWorkbench is not intended to be implemented by the clients, so adding a method would not be a breaking change. The window type id argument would be used to locate the matching window advisor and use it instead of the default one. 4) This can be done by simply adding a boolean attribute 'hideFromMenuBar' to the perspective element of org.eclipse.ui.perspectives extension point. The default value would be 'false'. If set to true, the perspective would not show up in the perspective chooser, but could still be created programmatically. The 1)-4) would allow UA component to create UA-related windows that can have the benefit of part management, tool bar and menu bar management but would otherwise be specialized (not general-purpose).
We'll also need special handling for always-visible action sets such as the Software Updates and Cheat Sheets ones. These should probably only appear in windows with the "default" window type (i.e. we don't want these showing up in the Help window). We may also want to allow action set <-> window type associations. Alternatively, allow a window type to promote a context, and have context <-> action set associations. Another approach to this whole thing, rather than introducing a new concept like window type, is to allow multiple Workbench instances, each with different advisors. We would need to share as much representation as possible (i.e. the various registries). Unfortunately, there's lots of code that assumes the Workbench is a singleton (API too: see PlatformUI.getWorkbench()).
(In reply to comment #2) > Another approach to this whole thing, rather than introducing a new concept like > window type, is to allow multiple Workbench instances, each with different > advisors. As always, my proposals for UI changes aim at as little refactoring as possible :-). Your alternative scares me because it represents a fundamental shift in the design, and I am not sure it is worth it for what we want to achieve.
(In reply to comment #2) > We'll also need special handling for always-visible action sets such as the > Software Updates and Cheat Sheets ones. These should probably only appear in > windows with the "default" window type (i.e. we don't want these showing up in > the Help window). The assumption is that once you can provide your own window advisor, you can choose which menus and actions sets are visible in the window. In case of help windows, I would start building the menu from scratch, selectively using existing action factories to populate the menu and the tool bar. However, my knowledge of window advisors is cursory and it is possible that what I am just saying makes no sense :-).
Re comment 3: Yeah, I know. I debated even mentioning it. Blame it on it being late on a Friday afternoon <g>. Having an explicit notion of window type will probably be useful anyway, e.g. for hanging other things like contexts off of. Re comment 4: The advisor does not control which action sets are visible, just where they are placed. For example, the IDE's action bar advisor (WorkbenchActionBuilder) has: bar.add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS)) in both the fillMenuBar and fillCoolBar methods, specifying between which menus or toolbars the action set contributions go. Since action sets are contributed via extension point, the set is open ended and the advisor can't know about all of them, and therefore can't be responsible for filtering them (likewise for any other extension point). I'm not sure what happens if you don't specify an MB_ADDITIONS group marker. It probably just adds action set contributions at the end if missing. So we'll need some way of narrowing what visible="true" means for an action set. Plus, if we allow customization of the perspective in different window types, we will want to restrict which action sets are even available for selection. This applies to other kinds of extensions too, like wizards, views, perspectives. Shortcuts for all of these can be configured per-perspective, or the whole set can be seen via Other... (assuming the advisor includes these menus). We may even want to filter commands and key bindings by personality. You can see why I started thinking along the lines of a separate workbench. But even then, we would want a different partitioning of the extension registry for different workbenches. We're actually pushing on a fairly fundamental difference between Eclipse, which has a bottom-up and open-ended registry of extensions forming a single global configuration, and other less open-ended systems like Spring which have a single-rooted configuration (i.e. a fixed tree of configuration files), but could (theoretically) run multiple instances on different configurations. Our only recourse with our current architecture is to introduce a new relationship, like "associated with window type" for each relevant extension point. To avoid having to do this for every single extension, we could adopt a pattern-matching scheme, as was done for the activities extension point. I'm not trying to scare anyone, and I think we should proceed with what you outlined above, but I'm confident we're going to run into this issue. Matt or James, can you comment on whether you've hit similar issues in the personalities work?
Re: comment #2 I have to agree with Dejan, supporting multiple Workbench's in an RCP application seems very scary to me. We've had problems with RCP components making the wrong assumption that there was only ever one WorkbenchWindow. This was true an a very early version of our product but when we moved to a model where we supported multiple WorkbenchWindows we needed to go back and refactor a lot of code. This is not to say that supporting multiple Workbench's per process isn't the absolute right approach. As for always visible actionSets, I think it's okay to replicate these across "window types". I believe Eclipse docs suggest that the visibility property of an actionSet be set to false 99% of the time and that an actionSet be associated with a relevant part or perspective. Following the "only contribute when relevant rule" you shouldn't have to worry about these types of actionSets. I think Dejan makes a good point in that one should be able to contribute a "window type" that is not extensible by standard Eclipse extension points. Meaning the Workbench should not do things like process actionSets (always visible or not) for the Window's menu or toolbar. Dejan I don't think this is possible now for menus. You may be able to do something funky with the Coolbar.
Re: comment #5 We did run into issues with cloned perspectives. With cloned perspectives the perspective association for actionSets or anything else starts to breakdown. How down. To workaround this we leveraged the activities feature of Eclipse, binding actionSet extensions to known activity extensions and mapping the activity extensions to an instance of a cloned perspective. We used a proprietary markup for the mapping. In the end the activity stuff became messy and we realized a limitation in that activities were global across workbench windows. Thus we could only support one instance of a "window type" that utilized cloned perspectives.
Matt, is the problem with cloned perspectives and action sets captured anywhere? It sounds like this is a separate issue that could be solved, e.g. with having a primary id vs secondary id (although as we know from multi-instance views, that approach has problems), or perhaps using contexts (e.g. perspectives P1 and P2 both promote context C; actions sets A1 and A2 are associated with C).
Secondary ids won't solve the problem we've had. The problem is that the clone is not known about at the time the actionSets are declared. So declarative association of actionSets to perspectives that are cloned is just not possible. We use Activities to work around this today. We could/should move to using contexts instead but we have not had the cycles to look at that yet. Moreover I think this is just a fundamental problem in working with cloned perspectives. The point I wanted to get at was that the activity matrix is global for all workbench windows. I think it would be useful to be able to scope enabled activities sets to an instance of a "window type".
Are there separate context services for each window? Activities, as Mat already noted are hobbled by being linked to the one workbench instance. I see a register shell method on IContextService which seems to indicate a window focus, but is that the case?
But if the primary id was kept, then the associations with it would still work (assuming they worked against the primary id, not the compound id). My current thinking is to keep activities global, but to give contexts more activity-like control over what is presented at the UI. Contexts can already be promoted on a per-window and per-part basis.
Reassigning bugs in component areas that are changing ownership.
I cannot commit to doing this at this point, but I'm marking it for investigation in M5.
Moving to M6, but unfortunately, I still cannot commit to anything.
I'm sorry but this did not make it into 3.3.
Prakash is now responsible for watching bugs in the [RCP] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
