Global shortcuts and i18n

[Lubos Lunak]

On Tuesday 05 of February 2008, Andreas Hartmetz wrote:
> 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(*)

 This is presumably not backwards compatible.

> 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.

 This seems to make things even more complicated than it already is.

 Facts:
- most global actions already do have objectName(), either because of being 
created using KActionCollection:addAction() with name passed (vast majority 
of them it seems), or they have it explicitly
- those that don't wouldn't work anymore, as you say

 Solution:
- use objectName()
- if it's empty, for backwards compatibility use text() and print a warning
- don't do anything more
- simple as that, unless I'm missing something

> 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.

 This somehow begs the question why it has been done this way in the first 
place, since this is exactly like it was in KDE3 :(.

 I'd support this, though, since that'd make simpler a couple of things that 
are IMHO wrong about kcmkeys right now, namely:

- the list of shortcuts right now is a random mess - KDE3 had them nicely 
separated by function and logically sorted, KDE4 has it all mixed together
- the combobox for the shortcuts component is a bad UI, as it's really hard to 
notice that there are more shortcuts than just those shown in the list, 
moreover what does 'kded', 'krunner' and similar mean to the average user?
- additionally, IMHO only basic components should be listed there, like in 
KDE3 - what's the point of having e.g. Amarok there?

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

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz