Feature request: ability to specify action for shortcuts

14 messages - 1859 views

It would be nice if it would be possible to specify which action is triggered when a shortcut is pressed. So for example in the screen widget I could specify:

shortcuts="left:showPrevScreen|right:showNextScreen"

I already made my own custom Screen widget which handles this. But this would be a nice feature in the core kuix also. I made some changes to Kuix - class to support defining your own Screen widget. I added a static method Kuix.setScreenWidgetClass(Class widgetClass) which stores the Class for screen widgets in a static variable and then in loadScreen I create the screen like this:

        Screen screen = null;
        try {
            screen = (Screen) screenWidgetClass.newInstance();
        } catch (Exception e) {
            screen = new Screen();
        }

That way I could override the way shortcuts are parsed and processed in my own screen widget.

Right, it was a choice to not associate shortcuts to a specific action, but with a widget.

By default, on AbstractActionWidget, shortcuts process the defined 'onaction'. It's right that it is a quite big limitation because an AbstactActionWidget could not have more than one action. But multiple shortcuts can point to this action.

In your case, action are not realy specific to a widget. This is general screen actions. If you have already a button or system menu to do those actions, you can put shortcuts on them. Else there is a problem right ;)

But screen is a particular widget and we can imagine something like that :

<screen actions="showPrevScreen:left|showNextScreen:right" />

In this case Screen do not derived from AbstractActionWidget and implements its own action strategy with shortcuts. And shortcut attribute would be ignored on Screen.

 

Yeah, I could specify the shortcuts to menu items etc. that I already have. But I was trying to achieve a way to browse the different screens that the application has by pressing left and right respectively. But I ran into trouble with the way framehandler handles the frame stack (see bug report forum for my post).

The way I handle the shortcuts in my custom screen is this:

    public boolean processShortcutKeyEvent(byte type, int kuixKeyCode) {
        if (isEnabled()) {
            String action = null;
            if (shortcutActions != null) {
                action = (String) shortcutActions.get(new Integer(kuixKeyCode));
            }
            if (action == null || action.length() == 0) {
                return processActionEvent();
            } else {
                Method method = new Method(action);
                Kuix.callActionMethod(method);
                return true;
            }
        }  
        return false;
    }

So basically I have a Hashtable with kuix key & action name pairs. It just checks to see if a key is mapped to a specific action, if not then the default action event is called.

Yes, but in you case you have to override the Widget.setShortcutKeyCodes() method and I'd prefer this one stay as simple as possible.

I'm not really overriding it. I'm just overriding the setAttribute - method of the Screen widget. And then first I parse the action names from the raw data that is given and the strip them and pass that raw data back to setShortKeyCodes just as before. So basically this modification only requires changes to the Screen widget. Which is not really that bad, but currently there is no way of providing your own implementation of the Screen widget unless you modify Kuix - class as I described in the first post.

But I think I'm moving on to different things for now. This is really not that big of a deal. And besides I ran into some trouble with the action handling using my modifications.

In the past I decided to make Screen an AbstractActionWidget to be able to use the 'onAction' and 'shortcuts' attributes, but it's right that even if this representation of shortcuts could be suffisant on a button or all other action widget the case o Screen is different. Ant in this case why not threat it in this context.

Else, I'm not very sure that give the possibility to define user class for screen is a realy good thing. A big part of Kuix logic is based on Screen and it could become very instable if we add the possibility to override the default Screen class.

 

Be sure I will try to improve the possibility to add shortcuts on Screen !

Okay. Thanks. I see your point about shielding the Screen class from changes. I myself just belong to the group of people that think that everything should be overriddable and replaceable by the developer. But then again, I don't have to provide support for Kuix :) So I guess it's easier if you limit the possibilities. How about providing a way to customise top bar and bottom bar :) That's what I really was after at first by wanting to provide my own implementation of Screen. I wanted to add some controls to the top bar of the screen.

After a long reflexion, I decided to hear your solution ;)

First shortcusts attribute is present on all widget and not only  AbstractActionWidget, then it is possible to extends its mission !

In this case, any Widget can define one or more shortcuts. By defaut on AbstractActionWidget, shortcuts process will activate action call, but on all other widget an action could be associate to a shortcut.

Then why put this attribte to a widget if it can call an independant action ? Because XML files contains widget only and because it could be retro compatible to the previous shortcut system.

How does it work ?

<screen shortcuts="*=myStarAction(this)|left=myLeftAction">

    <button onAction="myButtonAction(this)" shortcuts="5"

</screen>

In this example

  • * call myStartAction(screen)
  • left call myLeftAction
  • 5 call myButtonAction(button)

Shortcut would be already available from three type of events : pressed, repeated, released, respective attributes are : pressedShortcuts, repeatedShortcuts, releasedShortcuts. By default shortcuts attribte define the pressedShortcuts.

I tried adding shortcut to  menuitems, so I could circumvent this problem I had. Because most of the operation I wished to have the shortcuts for were already in the menu. But it seems that the shortcut does not work for menuitems ? Or at least nothing happened when I defined the menuitem as <menuitem onAction="something" shortcuts="left">Test</menuitem>

Only visible widget can intercept shortcuts. Then menuitem shortcuts work only if the popumenu is opened.

Excellent. I see that you have implemented this also in 1.0.0RC2.. Thank you very much. You seem to have forgotten this change from the Changelog though.

Right, the mistake is fixed ;)