[eclipse-incubator-e4-dev] news.eclipse.platform.rcp: Command handlers a

["Paul Webster" <pwebster@xxxxxxxxxxxxxxxxxxx>]

I think this thread contained valid questions for the E4 command architecture.

Mike Parker <mhparker@xxxxxxxxxx> 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