Rethinking global shortcuts

[Aaron J. Seigo]

On Thursday, February 7, 2013 13:43:46 Martin Gräßlin wrote:
> This situation *sucks*.

you just described exactly the problems i noted sometime around 4.0. i gave up 
trying to get change somewhere around 4.2 or so. the maintainer of the current 
system simply disagrees that what you and i find to be problems are problems. 
he feels/felt that he had chosen the lesser of evils.

fun, isn't it?

> 1. Define who gets modifiers. Given the way our shortcuts are nowadays, I'd
> say Alt belongs to Shell (Plasma+KWin) and Ctrl+Function keys belong to KWin

i agree we would benefit from documenting and segmenting ... this particular 
proposal is problematic: alt belongs to applications; control is mostly 
applications, but mostly frameworks stuff (ctrl+o, e.g.); meta is the window 
manager's as is ctrl+func ..

> 2. Allow new shortcuts to be registered if the application which had it
> registered before is not running

+1

> 3. Inform users about conflicts

possibly; not sure it will end up mattering to the user, but we can do it with 
a passive notification i suppose

> (4. Allow multiple applications to have the same shortcut and inform all of
> them if it is pressed, yes it sucks to not be able to use the forward media
> button for all media applications)

... or simply make it "first come, first serve"

i don't think it makes sense to have one key press do multiple things in 
multiple apps in a non-deterministic order. that seems to violate the 
principle of least surprise, and i can't imagine the use case. can you?

so they should remain exclusive, but runt-time flexible imho

>From a technical point of view I just want to note that with Wayland input
> handling moves in the compositor anyway, so we need to work on it either
> way. I would prefer to get the global shortcut handling already right now
> into KWin as we have to fight quite badly with the system (common examples:

if it means moving it out of kded, then the usual objection ensues -> this 
will not work without kwin, which means to get global shortcuts one will 
*have* to run kwin.

do i care about this in Plasma Desktop? not tremendously much as i'm ok with 
saying "plasma desktop and kwin rely on each other", though it will hit anyone 
who uses the "start other window manager" feature(/bug? ;)

will application developers care? probably, as it means all KDE applications 
(e.g. media apps) will lose their global shortucts when run in another desktop 
environment. that is not fair to them.

one way around this could be to have the shortcut handling encapsulated in a 
library and kded would be simply be a backup, but kwin would normally take the 
dbus interface over.

this means slightly more overhead (a kded module that sits and simply listens 
to the global shorcuts) but should be possible.

another possibility is to move all global shortcut handling into the 
applications themselves and have no external process handling it at all. the 
immediate benefits:

* no extra processes :)
* if the application is not running (or claimed the shortcut) there is no 
conflict

the immediate problems:

* if a global shortcut is claimed ... how does it know? :)

this implies the need for a temporary global registry somewhere. that *could* 
be simply a shared cache of "shortcuts that are actively in use" which the 
applications cooperatively populate and check. KSharedDataCache could serve as 
the repository.

* centralized configuration?

we don't have change notification on our configuration files (which routinely 
leads to suckage). if we did, this would be a non-problem. otherwise, watching 
files on disk would mean another filewatch per app using global shortcuts. not 
the end of the world, perhaps .. but also not awesome.

dropping centralized config isn't a great option since they are *global* and 
in-application config means hunting through every app to configure them.

assuming we don't migrate to a config system with change notification, then 
possibilities might include:

- a file watch on the app config per application
- a signal to listen to when config changes, much as we do with icon and other 
changes.


personally, i'd love to see the "no external process" method as it means less 
IPC, less overhead and fewer context switches. 

this would mean work on our part in the kglobalshortcut code in kdelibs for 
frameworks 5 and would imply that we take full maintainership of this area of 
things.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130207/1bd5efdc/attachment.sig>