[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [riena-dev] On disabling standard commands
|
Hi Stefan,
I would need to research this a little bit, maybe in the next sprint.
However from my memory I would say that you are right -- i.e. if the
riena keybindings are in their own context that would solve it. The
problem here is that then you always need a plugin_customization.ini.
:-(. Ideally I would wish there is a way to change the default context
/ keybinding scheme without the plugin_customization.ini since it is
difficult to explain to developers. I think you have a similar problem
(i.e. need to use plugin_customization.ini).
One thing you could try is if the <sequenceModifier> element of the
'org.eclipse.ui.bindings' extension point - according to the
documentation you can find a keybinding (example M1+PAGE_UP) and
replace it with something else. If it works (haven't tried) you could
potentially replace the default bindings without having to define your
own scheme and bindings:
<sequenceModifier
find="M1+M2"
replace="M2+M3"
platforms="win32,gtk,motif,carbon" />
The Riena keybindings are currently all in
org.eclipse.riena.navigation.ui.swt/plugin.xml.
Kind regards,
Elias.
On Thu, Aug 20, 2009 at 12:59 AM, Flick,
Stefan<Stefan.Flick@xxxxxxxxxxxx> wrote:
> Hi Elias,
>
> I tried to "overload" the new Riena KeyBindings with some new requested by our Customers LnF Policy.
> So I just define some new KeyBindings for already existing Riena commands (especially nextView etc.).
> My KeyBinding is defined in an own Context extending the default Context org.eclipse.ui.contexts.window.
> The Riena KeyBinding is also defined in this context.
>
> <extension point="org.eclipse.ui.contexts">
> <context id="ruv.context"
> parentId="org.eclipse.ui.contexts.window"
> name="RuV NVUS Keyboard Context">
> </context>
> </extension>
>
> In my application class I switch once to the own context like that:
>
> IContextService cs = (IContextService)PlatformUI.getWorkbench().getService(IContextService.class);
> cs.activateContext(RUV_KEYBOARD_CONTEXT_ID);
>
> I add new KeyBindings and overwrite existing ones from Riena.
>
> <!-- **********************************************************************
> Additional Key-Bindings
> *********************************************************************** -->
> <extension point="org.eclipse.ui.bindings">
> <!--
> ATTENTION: if you change this scheme id, pls. check also
> the plugin_customization.ini file and the class PilotApplication
> which will refer to this Id!!!
> M1==Ctrl, M2==Shift, M3==ALT
> -->
> <scheme id="ruv.scheme"
> name="RuV NVUS Keyboad Schema"
> parentId="org.eclipse.ui.defaultAcceleratorConfiguration" />
> <key commandId="ruv.global.histforw"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+F6" />
> <key commandId="ruv.global.histback"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+M2+F6" />
> <key commandId="ruv.global.print"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+P" />
> :
> :
> </extension>
>
> <!-- **********************************************************************
> Overwrite Riena Keybindings
> *********************************************************************** -->
> <extension point="org.eclipse.ui.bindings">
> <key commandId="org.eclipse.riena.navigation.ui.nextModule"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+F7" />
> <key commandId="org.eclipse.riena.navigation.ui.previousModule"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+M2+F7" />
> <key commandId="org.eclipse.riena.navigation.ui.nextSubApplication"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+F8" />
> <key commandId="org.eclipse.riena.navigation.ui.previousSubApplication"
> schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"
> contextId="ruv.context"
> sequence="M1+M2+F8" />
> </extension>
>
> Everything is fine. My Keybinding is active and I can use M1+F7 to switch thru the Modules. But M1-PageDn (defined by Riena) is also active. This is not really a problem, but in my application menu I see the KeyBinding from the parent Context (M1-PageDn) and not my own binding M1+F7. That is definitely not what our Customer expects.
>
> Is there a way to remove the original Keybindings from Riena or specify which one is the one to show on the menu? What is the correct way/pattern to change Keybinding without declaring everything redundant in an own context which is not a child of org.eclipse.ui.contexts.window? Where can I find a list of all existing Riena Bindings? Is it just in the plugin.xml of o.e.r.navigation.ui.swt?
> What is with the keyboard schema? I can't find an API to activate a specific schema analog to the context (except entry in plugin_customization.ini)?
> Any ideas?
>
> I found the following in the documentation related to the NOP handler solution. Never tried out, but maybe this is an alternative way...
>
> "If a binding does not define a command identifier, then it is a deletion
> marker. This means that if all the conditions are met, it will cancel
> any bindings with the same trigger in the same context. This mechanism
> can be used, for example, to change a binding on a particular platform."
>
> Regards, Stefan
>
>
> -----Ursprüngliche Nachricht-----
> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Elias Volanakis
> Gesendet: Donnerstag, 20. August 2009 02:03
> An: Riena Developers list
> Betreff: [riena-dev] On disabling standard commands
>
> I've been asked to post how I "disable" some standard commands that do
> not make sense for Riena. This are commands such as nextView,
> previousView, nextPerspective, previousPerspective (bound to Ctrl+F7,
> Ctrl+F8 and other keys).
>
> My solution was to install a 'Nop-Handler' for this commands, i.e.
> this handler does nothing:
>
> IHandler handler = new AbstractHandler() {
> public Object execute(ExecutionEvent event) throws ExecutionException {
> // Do nothing by design
> return null;
> }
> };
>
> The handler is associated with problematic commands via java-API. This
> happens in ApplicationAdvisor#overwriteStandardHandlers(). You'll find
> the details here.
>
> I would not call this a best practice but it works well for my
> purposes (unfortunately the whole extension point system is designed
> primarily about the notion of adding stuff - not removing).
>
> Hope this helps,
> Elias.
>
> --
> Elias Volanakis | Technical Lead | EclipseSource Portland
> elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
--
Elias Volanakis | Technical Lead | EclipseSource Portland
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com
