Global shortcuts and i18n
ahartmetz at gmail.com
Tue Feb 5 22:26:23 GMT 2008
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(*)
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
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
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,
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
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 :) )
More information about the kde-core-devel