Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [riena-dev] On disabling standard commands

Hi Ekke,

 

I spend some time to investigate and play around.

 

As I see so far it would be great, if the Riena keybindings are placed in an own Riena context, derived from the root context.

To disable this bindings its necessary to define all wanted bindings again in the own context, but in the moment when the context is switched, the default Riena binding is not longer part of the dependency chain and did not appear on the menu…

But for that we have to change the Riena… maybe there is another solution?

 

Stefan

 

 

 

Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von ekke
Gesendet: Donnerstag, 20. August 2009 10:17
An: Riena Developers list
Betreff: Re: [riena-dev] On disabling standard commands

 

Stefan,

great that you're asking this.
In my RCP app I also have the need to define customer-specific key bindings
and am looking for the best way how to use my own Keybindings together with Riena Keys (and without unwanted standard keys)

(and I have to I18N the keybindings)

ekke

Flick, Stefan schrieb:

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.
 
  

 

--

ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490


Back to the top