I think this thread contained valid questions for the E4 command architecture.
Mike Parker <[EMAIL PROTECTED]> commented on another thread: Paul Webster wrote: > For the true "one default handler for all of eclipse" there is API missing in > 3.3 to do what you want. https://bugs.eclipse.org/bugs/show_bug.cgi?id=205044 > > Most commands solve this problem by having one handler per workbench window > or one handler per editor ... using > workbenchWindow.getService(IHandlerService.class) and then > handlerService.activateHandler("id", handler) will restrict that handler to > being active within one window. Within a part, getSite().getService(*) will > restrict the handler to only being active within that part. > > Later, > PW > Paul, I'm not sure you're answer is correctly addressing Mark's question. As I see it, the problem is not directly related to the handlers, but to the commands themselves, which (being typically defined in the plug-in's plugin.xml file) are instantiated by the platform only once. Thus, if two command contribution items in two workbench windows are associated with the same command ID, they are also referencing the same command object. Since this command can, in turn, only be associated with (at most) one handler at any one time, and this handler is responsible for determining the commands enabled status, it is (as Mark says) impossible to enable the command contribution item in one workbench window, whilst keeping the command contribution using the same command ID in the other workbench window disabled (or vice versa). As an example, suppose we have two workbench windows, both with an active editor. Suppose also that one of these editors has outstanding (i.e., unsaved) modifications, and the other one doesn't. In this case, the "Save" toolbar item (for example) would be expected to be enabled in the first workbench window, but disabled in the second, which is (with just one shared command, with one currently installed handler) impossible to achieve with the current Platform Command Framework (PCF). The best that one can theoretically do in this case is to set the handler's enabled status based on the active workbench window, and tolerate the fact that this status is then inappropiate for the inactive workbench window. Thus, assuming that the background window were the one with the non-dirty active editor, this would give the user the mistaken impression that a Save is possible there, too. However, on switching to that background workbench window, the "Save" toolbar item would suddenly become disabled. It's a bit like chasing the rainbow's end, only to find out that, when one finally gets there, it's gone! Note that this problem does not exist with menu items, because one cannot show the (popup) menu items for a background workbench window without first activating it. However, the above-mentioned problem does NOT occur with the "Save" toolbar item in Eclipse 3.4. In other words, if two workbench windows have (respectively) a dirty and non-dirty active editor, the "Save" toolbar item for the workbench window with the dirty editor remains enabled, regardless of whether the window is active or not. Likewise, the "Save" toolbar item for the workbench window with the non-dirty editor remains disabled, regardless of whether the window is active or not. Exactly as one would expect. Unfortunately, a brief look into the source code for Eclipse 3.4 with the aim of finding out how this was achieved revealed the answer: the "Save" operation (unlike some others, such as "Delete", "Print" etc.) has not yet been updated to use the PCF, and is still action-based. As such, separate Action instances are created for each workbench window, each with an independently settable enablement status, and each of which only concerning itself with the changes in its "own" workbench window (passed to the action as constructor argument). Of course, it's not just "Save" operations that are affected. In my experience, the vast majority of user operations are related to the active selection, active part or active editor, all of which are workbench window-specific. The problem described above can be best illustrated in Eclipse 3.4 with the "Print" command, as follows: 1) Start Eclipse 3.4, specifying a workspace containing at least one file editable via the Text Editor. 2) Close any editors. The "Print" toolbar item should now be disabled. 3) Open a new workbench window via "Window > New Window" 4) Open the Text Editor on a workspace file. 5) Note that the "Print" toolbar item is now not only (correctly) enabled for the new workspace window, but is also (incorrectly) enabled for the original workspace window, even though there is nothing to print there. (Note: Maybe this should be bugzilla'd, so that we have a handle on this problem?) In order to fix this issue, surely it would be necessary to (optionally) instantiate a command once per workbench window, rather than once per workbench. In theory, all command instances with the same ID could conveniently share the same handler, as long as this handler could determine which window it's meant to be working on (e.g., IsEnabled(IWorkbenchWindow window) ??). Anyone got any other thoughts on this? If so, please provide some feedback here. Thanks in advance. Cheers, Mike -- Paul Webster Hi floor. Make me a sammich! - GIR _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
