Bug 426773 - SelectAll not bound on JFace viewer
Summary: SelectAll not bound on JFace viewer
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.3.1   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-28 05:20 EST by Sebastien Pennec CLA
Modified: 2014-01-28 09:03 EST (History)
2 users (show)

See Also:


Attachments
SelectAllHandler (5.71 KB, text/plain)
2014-01-28 08:59 EST, Sebastien Pennec CLA
no flags Details
WidgetMethodHandler (7.24 KB, text/plain)
2014-01-28 09:00 EST, Sebastien Pennec CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Pennec CLA 2014-01-28 05:20:01 EST
When migrating my application from E3 to E4, I've found the following bug.

- Create a viewer with multiple selection in a dialog
- Run it in E3 and ctrl-A -> the items are all selected.
- Run it in E4 and ctrl-A -> no items are selected.

When debugging in the BindingTableManager, I can see that the correct binding is tested, but there is no handler associated with the select all command.

If I add an handler for the select all command, it is executed correctly. I think that it should be handled by default.

I also checked that my binding contexts are similar to those found in Eclipse when I open the Live Application Model.

I am working with Olivier Prouvost on this and he tested the same behavior on his Mac, so the bug is not "Windows 7-only".
Comment 1 Sebastien Pennec CLA 2014-01-28 05:22:55 EST
In another part of my app, there is a GEF viewer. The viewer correctly handles the shortcut.
Comment 2 Lars Vogel CLA 2014-01-28 05:45:35 EST
AFAIK Eclipse 4 RCP does not provide default keybinding, in this case this would work as designed.  But I put it into the platform queue so that other can check that.
Comment 3 Paul Webster CLA 2014-01-28 05:58:05 EST
The commands aren't handled at the JFace level, but at the Application, Window, or Part level.

In 3.x the workbench defines a dialogAndWindows keybinding for things like cut, copy, and paste but as Lars mentions in Eclipse4 if you provide the base model then you don't have any default keybindings.

In 3.x that behaviour is provided by org.eclipse.ui.internal.handlers.SelectAllHandler.  In theory we could provide similar handlers that could  be used by Eclipse4 RCP apps.

PW
Comment 4 Sebastien Pennec CLA 2014-01-28 07:25:12 EST
Hello,

Thank you for your answers.

As a workaround, I implemented my own version of E4 SelectAllHandler, based on org.eclipse.ui.internal.handlers.SelectAllHandler. It works as expected.

As for the fact that such handlers should be provided by Eclipse, I would argue that if it was provided by E3, it should be provided by E4. This is kind of surprise that people won't really like when they migrate from E3 to E4.
Comment 5 Lars Vogel CLA 2014-01-28 08:50:29 EST
(In reply to Sebastien Pennec from comment #4)
> As a workaround, I implemented my own version of E4 SelectAllHandler, based
> on org.eclipse.ui.internal.handlers.SelectAllHandler. It works as expected.

Can you attached you implementation as reference?
Comment 6 Sebastien Pennec CLA 2014-01-28 08:59:47 EST
Created attachment 239387 [details]
SelectAllHandler
Comment 7 Sebastien Pennec CLA 2014-01-28 09:00:08 EST
Created attachment 239388 [details]
WidgetMethodHandler
Comment 8 Sebastien Pennec CLA 2014-01-28 09:00:37 EST
I have attached the classes.

It's basically a copy/paste of the org.eclipse.ui.internal.handlers.SelectAllHandler and its parent class org.eclipse.ui.internal.handlers.WidgetMethodHandler.

We cut the inheritance to AbstractHandler and IExecutableExtension and ported the management of the baseEnabled attribute to the WidgetMethodHandler. 

We also added an initialization of the methodName attribute in the constructor of the handler with the "selectAll" value.

Finally, we also removed the execute method of WidgetMethodHandler since it's overriden in the child class.

This is possibly the worst way of making this work... it's a quick and dirty workaround, nothing more.