Global shortcuts and i18n

[Andreas Hartmetz]

Hi all,

There is a big (by popular vote, even!) problem with global shortcuts. The 
global shortcuts registry aka KdedGlobalAccel associates keys with i18ned 
K/QAction names. As we have previously conluded (in IRC IIRC) there is no way 
to create a both unique and repeatable (over several runs, versions...) ID 
for actions automatically. That means that programmers need to assign a 
unique ID to each action that is supposed to use global shortcuts.
Unfortunately this is not how it works now so there is the additional hurdle 
of making the transition.
What's more, the semantics of global shortcuts are not very intuitive (which 
seems to be unavoidable given the constraints) but there is some room for 
easy improvements, especially together with the previous point.
I propose the following change to KAction:


setGlobalShortcutAllowed(bool);  //deprecated and redefined as a no-op(*)
|
v
enableGlobalShortcut(const QString &uniqueName); //uniqueName is allowed to be 
empty if the objectName() is not
disableGlobalShortcut(); //I expect ~1 use throughout KDE svn, but for 
symmetry...

The uniqueName would be passed to setObjectName() just like when you insert an 
action into a KActionCollection by name. Also just like with 
KActionCollection, if you pass an empty string and the objectName is already 
set then the objectName will be used instead. This is a nice symmetry - you 
can set the name once and never again, or set the same name as often as you 
want - it's forbidden to change it though.
(*) except if the action has an objectName() already. Many do because 
inserting into a KActionCollection by name assigns the name as the 
objectName.

That would be binary compatible in a "still compiles, links (also dynamically) 
and runs" sense. It would not be BC in a "no change in behavior" sense 
because global shortcuts would stop working for unported applications that 
don't, by chance, assign objectNames to their actions.
Sorry, there seems to be no cleaner fix. I could think of really convoluted 
ones that would also be very unreliable because if you don't have a unique ID 
per action then you have no fixed point to make the right associations. It 
would take much time to code and be buggy and unpredictable.

Note that KdedGlobalAccel is not designed to be, and not very suitable, to 
implement things like a KControl module for KWin that does not live in the 
KWin process. That can still be done but the i18ned name of the action will 
not be obtainable through this system - the KCM just needs to bring the 
knowledge on its own.
You'd really have to store all i18ned names in the global config file for all 
the languages the KCM might want to use. That sounds like a corner case (and 
it is) but corner cases need to be considered - who actually wants to run KDE 
in different languages and expects global shortcuts to keep working. Oh, 
right...
More importantly, it doesn't feel right to me and you can't argue with me 
about that. Ha.
No big issue for KWin and so on I think, you just need additional data files 
(maybe compiled in) for the respective KCMs - they should "know" their 
shortcuts anyway.
As a side effect, the code dealing with getting and setting default shortcuts 
could be removed from KdedGlobalAccel again. No offense to Aurélien who did 
this IIRC, I was just not doing anything in past couple of weeks so I didn't 
intervene earlier. Especially the README is also appreciated and I hope to 
improve it soonish (Hello Lubos, I am not ignoring your request on 
purpose :) )

Cheers!