Global shortcuts and i18n

[Andreas Hartmetz]

Am Mittwoch 06 Februar 2008 15:09:37 schrieb 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?)
>
The number is quite limited, yes. The total number of global shortcuts in all 
applications is also limited.

> > 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.
>
OK, and if the signatures don't differ let's use 
setGlobalShortcutEnabled(bool). It's a better name than 
setGlobalShortcutAllowed(bool). The mechanism itself is a little tricky and 
this will help somewhat.

> > 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.
>
I would like to avoid such corner cases, but see below. There is not much 
choice really.

> > 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...
>
I can't argue with that.

> > 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).
>
I forgot one thing - for conflict resolution it is generally good to know the 
name of the other action involved so the human readable name has to be 
available to all applications anyway.

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

You can't assign conflicting shortcuts. That is one of the things the new 
system is good for.
I don't have an opinion about which shortcuts you should see in the KCMs.

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

OK, if the data file solution sucked it should be avoided I guess :)
It also wouldn't hurt to store friendly names for the components and make them 
available then.