Community
Participate
Working Groups
When a trim control has focus, it should be able to specify that its handlers are active. PW
Created attachment 61144 [details] Proposed API v01 This is the proposed API for tracking the registered in focus control. PW
Created attachment 61145 [details] Actual (mostly) working code v01 This is the backing that I'm working on ... in progress. PW
Created attachment 61155 [details] Proposed API v02 This is the API proposal: 2 constants on ISources plus the IFocusService. When the trim control(s) are created, they call the IFocusService: Text tw = ...; IFocusService fc = (IFocusService) getWorkbenchWindow().getService( IFocusService.class); fc.addTrackerFor(tw, getId()); Then they can create expressions and use them to use their own handlers. ACTIVE_FOCUS_CONTROL_ID is one of the highest priorities for resolving conflicts. For example, to provide a widget paste handler to the control registered as org.eclipse.ui.tests.focusText: <handler class="org.eclipse.ui.internal.handlers.WidgetMethodHandler:paste" commandId="org.eclipse.ui.edit.paste"> <activeWhen> <with variable="activeFocusControlId"> <equals value="org.eclipse.ui.tests.focusText"/> </with> </activeWhen> </handler> PW
Created attachment 61156 [details] Focus Service implementation v02 The implementation patch. PW
Created attachment 61159 [details] Focus Service implementation v03 Updated patch with constants for default cut/copy/paste/selectAll behaviour. PW
+1
Created attachment 61190 [details] Focus Service implementation v04 Update service with some more documentation. The API now consists of 2 constants in org.eclipse.ui.ISources, and the IFocusService interface. It contains 4 constants whose values can be used to provide default cut/copy/paste/selectAll behaviour. It also contains 2 methods to add and remove a control from the focus service. PW
Dani, I'm interested in your opinion on this Focus service. Our first usecase is to allow a trim widget that has focus to specify its own commands and provide handlers to known commands (like cut/copy/paste). But it's written in such a way that any Control that can take focus can have commands and handlers associated with it. PW
re: IFocusService: reading its Javadoc and not being familiar with the internals it is not quite clear what 'track' actually means. Why is it in ui.menus? Is it restricted to menus? Would this mechanism also allow to generally extend an SWT widget with a command? An interesting use case is for example to provide camel case navigation actions for standard SWT controls. Currently JDT UI has its own hacks to provide this and of course this only works in wizards and dialogs provided by JDT UI.
Created attachment 61272 [details] Focus Service implementation v05 Minor modification to the patch. Let's try org.eclipse.ui.swt.IFocusService since it's specifically to handle SWT controls. And I've slighly re-worded the addFocusTracker(*) javadoc. PW
(In reply to comment #9) > re: IFocusService: reading its Javadoc and not being familiar with the > internals it is not quite clear what 'track' actually means. Why is it in > ui.menus? Is it restricted to menus? I've moved it to an org.eclipse.ui.swt package, since it's actually an SWT Control service. > Would this mechanism also allow to generally extend an SWT widget with a > command? An interesting use case is for example to provide camel case > navigation actions for standard SWT controls. Currently JDT UI has its own > hacks to provide this and of course this only works in wizards and dialogs > provided by JDT UI. I guess it depends on what you mean by extend. It provides a registered SWT control that's in focus as a variable (well, 2) for evaluation by the services. That means it can be used in core expressions, and that it'll show up in the application context passed to a handler during execution. It will allow an SWT control to provide its own handlers ... for as long as it's in focus. You could use it to active a programmatic context contributed through the IContextService, or to activate a declarative or programmatic handler with an activeWhen clause. In our case, we're activing appropriate handlers for cut/copy/paste/selectAll. PW
>I guess it depends on what you mean by extend. I meant to contribute a command (and its action) to e.g. the SWT Text widget so that it's available globally in all Text widgets.
(In reply to comment #12) > I meant to contribute a command (and its action) to e.g. the SWT Text widget so > that it's available globally in all Text widgets. Ah, I see. Initially it won't support that, since each Control has a unique ID. However one of the enhancements we are considering post 3.3 is to allow multiple controls to specify the same ID. Then all text widgets that registered with that ID would get all the same handlers (and their commands). Should we consider allowing multiple controls to register the same ID now? PW
Released into HEAD for the 13:00 EDT I build. I've removed the one-to-one restriction on controls to IDs, it's now many to one. PW
I20070320-1620 PW
*** Bug 154268 has been marked as a duplicate of this bug. ***
