Global shortcuts and i18n

[David Faure]

On Tuesday 05 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.
OK.

> Unfortunately this is not how it works now so there is the additional hurdle 
> of making the transition.
Yes (fortunately the number of apps with global shortcuts is rather limited I think?)

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

OK for enableGlobalShortcut/disableGlobalShortcut, but I don't think the name should be passed to those methods.
If the application that creates the action [with a global shortcut] has to name it, then let's write setObjectName in the application code.

> 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.
... which shows that using the objectName is what we want, simply :)

> 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.
Yes, let's name those 20 actions or so.

> 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. 
I disagree, it seems like a nice solution to me. This way we have a nice place
where to get all the global shortcuts from, instead of the ugly #include hacks that
we used to do in kdebase. At some point I had in mind that apps should install
some text file somewhere, but that would suck too, it's much better to just get
all the info from kdedglobalaccel.

> 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.
Why? Surely the applications can give the i18n'ed text of the action to kdedglobalaccel.
When you change language you'll have to restart kde for that bit to be updated, no big deal there.

> More importantly, it doesn't feel right to me and you can't argue with me 
> about that. Ha.
I'm sorry but you can't leave things broken for two releases and then come back
and act as the "all-powerful maintainer". All powerful maintainers are ok if they
are active maintainers, but this wasn't the case here, two people needed to iron
out critical bugs and missing features for 4.0 and 4.0.1, you have to accept their input now...

> 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.
It's far more complicated if we have to teach every user of global shortcuts to
install a data file, compared to Aurélien's nice solution of "just making it work",
using the existing infrastructure (kdedglobalaccel).

On the other hand I don't agree with Lubos that only core components should
be in kcmkeys. If you assign a global shortcut to a kwin action then you'd better
see the amarok global shortcuts too, to make sure you don't choose the same shortcut
for two actions with global shortcuts.
The KDE3 solution sucked because it was all hardcoded, no way for apps not in
kdebase to show up in the global shortcuts config module. The kded module
(with Aurélien's solution) solves this nicely.
However I do agree with Lubos that we shouldn't show "kded"/"krunner", but translated 
names for the components, of course; this is just another string to pass to the 
kded module together with the component name.
"separated by function and logically sorted" can be achieved by setting a "group"
property on the actions (translatable name), and kglobalaccel would pass that group
along to kdedglobalaccel.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).