Keyboard shortcuts and applets

[Aaron J. Seigo]

On Sunday 12 April 2009, Emdek wrote:
> 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).

yes, i don't think it's worth it for the 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.

no such thing. we call focus() on the widget, which should give it keyboad 
focus. at the very least, this should allow one to start moving between 
widgets in the same containment using the keyboard.

> 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);

a widget offering additional global shortcuts on its own is going to usually 
be a bad idea (they are in limited supply), but what we could do easily this:

when creating the shortcuts page, go through all actions in d->actions and add 
them to the page.

voila: the keyboard shortcuts page has all shortcuts defined, global or local.

we'd probably want to have a whitelist of actions that are global to all 
widgets (configure, remove, etc) and have those in the global plasma dialog.

> 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 no case 1, and the developer should have zero say in how the page 
looks. every time you feel that a widget should have some special way of 
showing the world just how special it is, go find a kitten and kill it. you'll 
be saving god the effort. ;)

> 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)?

the confusion here is that you think this has something to do with the 
widget's programming. it doesn't. the developer of the widget has nothing 
whatsoever to do with this shortcut. none. zero. zip.

the widget _may_ respond to the activate() signal.

it just so happens the activate() signal is triggered by this global shortcut, 
but that's an implementation detail and nothing more.

the shortcut is there for the *user*, specifically to give the *user* a way to 
define how to interact with and control their plasma components.

this way of thinking is part of the plasma way.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090413/23f0d0ff/attachment-0001.sig