Keyboard shortcuts and applets

[Emdek]

On Sunday 12-04-2009 18:23:00 Aaron J. Seigo <aseigo at kde.org> wrote:
> On Sunday 12 April 2009, Emdek wrote:
>> If yes, I think that that there should be added information in
>> configuration, for what is that shortcut intended. Or maybe separate it
>> from rest of applet configuration
>
> what benefit is there to this? the downsides would be more entries in  
> context
> menus, having to provide more buttons in the applet handle and having to  
> visit
> more places for configuration which in turn requires the user to build a
> detailed mental model about "what kind of configuration i'm doing"

Ok, right, but there maybe should be at least some description for that keyboard shortcut (only general, adding possibility to set own for each applet could be maybe useful, to explain what it do in that plasmoid, but then we need a way to set this information etc., and this could be too big problem and not too big benefit).



>> Additionally there is problem which I've mentioned earlier:
>> > One thing is clear (at least for me ;-)), that using applet's activate
>> > signal for unhiding autohidden panels should be separated from  
>> activation
>> > that comes from activation of applet's keyboard shortcut, because when
>> > you want also to use it to perform action (for example show menu or
>> > something) it will be triggered when trying to unhide panel (I saw  
>> this
>> > in Tasks applet and I can't use it my plasmoid, Fancy Tasks, because  
>> I'm
>> > using shortcut for displaying menu).
>
> and for widgets where the activation results in giving focus to an  
> editable
> text area? obviously the panel can't know what the activation is going  
> to do.
>
> perhaps a way could be found to ensure first that the containment is  
> visible
> and once it is then actually perform the activation in Applet.

This problem maybe could be solved by adding signal that is emitted only when shortcut is activated (or adding optional boolean parameter to current signal)?
Documentation says that triggering shortcut is only one of cases when this could be emitted (what if there will be more added in future), but sometimes we only want to trigger action for keyboard shortcut.
This and previous problem could be also solved by adding possibility to replace current shortcut page with custom, described below.



>> I'm not sure if these shortcuts should be used to preform action, some
>> applets doesn't provide actions that could be triggered or have more  
>> than
>> one action that could be handy if possible to access it using (global)
>> shortcut (maybe we need more flexible mechanism to add actions and GUI  
>> for
>> configuring them).
>
> then those applets need to provide global shortcuts for those actions;  
> but i
> really don't think there's a common need for such a thing, while there  
> is a
> common need for "activate this given widget" and it should work  
> identically
> for all widgets.

Ok, but I still see two possible cases:

1. Plasmoid doesn't need and doesn't use keyboard activation.
Then we get configuration dialog with only one page with option that does nothing.

2. Plasmoid has more than one global shortcut and they are configurable.
Then we get two pages with shortcuts, for example:
- Keyboard shortcuts (custom actions);
- Keyboard shortcut (default page for all applets);

I know that standard solution for every applet is nice and enough in most cases but maybe developer should have possibility to decide how looks page with shortcuts (case 2.) or disable it when there is no need for any (case 1.).
There is method called setHasConfigurationInterface(bool) but now all applets always have at least one option to set so always they needs interface. 
Maybe setting this to false (or when not set at all) that page shouldn't be added (or kind of method or something to disable this page, could be useful also when we want to replace it be custom page with more shortcuts for example)?