Finding shortcut

[Michael Jansen]

> unfortunately, the status quo here completely doesn't work for plasma and
> the way we're handling those global shortcuts has been labeled as
> incorrect. unfortunately, incorrect or not, it is precisely the behavior
> needed.

The one thing i remember labeling incorrect is when there were no real unique identifiers used.
An widget used a different objectName for a shortcut when plasma restarted and it had been moved.
And that WAS wrong in terms of global shortcut code.

> the other comments in that code block about global accels are not
> sarcastic, they are clear statement of fact about the impacts on that
> particular set of decisions as well as current limitations imposed by the
> startup sequence of the kde workspace in relation to config file updates
> and the daemon managing the global accels. _none_ of that stuff is obvious
> until you actually look into the system as a whole and begin to realize
> that those "obvious" solutions actually won't work in practice. iow, they
> explain why the rather odd looking line that follows the comment is as it
> is.

I hope you realize that exact problem exists with more/many kde daemons?

> unless i've missed it (and i keep hoping i have) there is no clean solution
> for changing an application name (e.g. plasma -> plasma-desktop) and
> migrating the accels.

There is none because we never had the need. Noone said there never will be an api or we will
never add it. Is plasma's api complete? Should i by the missing of some method assume you never
want to support the use case i need that method for?

> nor is there any really good way of having global accels associated with
> dynamic UI components that can come and go (and even have the same
> accelerator in two components as long as they aren't simultaneously
> active/loaded) without managing the lifespan in your application.

That's correct. The solution i once proposed and told you about is "global shortcut contexts". The
possibility for an application to have more than one set of global shortcuts and the ability to
switch between them. The code is btw. there KGlobalAccel::activateGlobalShortcutContext. And i'm
pretty sure i told you about it.

It probably has problems but it was implemented especially and only for plasma. And it has
problems because it was never used.

( I will call those dynamic ui components contexts in the next sentences. Because component is
taken in kde land. What i have in mind is the possibility to switch between totally different
plasma-desktop configurations. With different widgets and shortcuts and virtual desktops ... . If
this is not correct please explain what you mean by dynamic ui components. )

> note that i'm completely happy with managing the lifespan manually within
> libplasma, though i'm of the understanding you feel that is not
> appropriate. i'm not completely happy with the "component isn't
> registered, but its accels are still protected", though i understand you
> think it is fine. :)

That is not 100% right. It really depend on the use cases you have in mind. If you think about
switching between those dynamic contexts many times a day i prefer that the global shortcuts stay
registered and reserved.

Its absolutely possible for plasma to remove all their global shortcut registrations at once. Even
today. With the available implemented api. See KGlobalAccel::cleanComponent. The code is there for
quite some time. It's even documented. But perhaps that could be improved. But There is one catch.
Only inactive global shortcuts are removed. You would have to destroy the KActions before calling
the method. I implemented it for two purposes:

1. Amarok? in the past had a small accident and renamed all their global shortcuts. Instead of
   cleaning up manually one by one we just activated all wanted global shortcuts and called that
   method. The rest vanishes. Or i did it after that to never have to remove them one by one.

2. There is no way to automatically remove global shortcuts. We never know if a user stops using
   an app and/or deinstalls it. We never really notice if an applications changes it component
   name without migratiing it shortcuts. So our global shortcuts registry fills up. The dialog now
   has the possibility to clean it by calling the above method.

And i decided to only remove inative global shortcuts to prevent misuse (by accident or by
intention) and because it makes no sense to remove a global shortcuts if we know it is active.

Back to your problem: If you want to do this when switching contexts how do you like to handle the
case that on switching contexts plasma is not able to reclaim a global shortcut because

1. The user assigned it to some other app? Perhaps not recognizing it's assigned in his other
   context?

2. The user started some new never_started_before app that claimed it?

Do you want to popup a dialog asking him what to do? Do you want to ignore the problem silently?
Perhaps frustrate your user because the app is doing the wrong thing and on pressing the key combo
just does nothing because there are no new messages ( arbitrary example :) ). And he sits there
and wonders why the dumb plasma stopped working.

That's why i would like to keep them registered if the use case is switching often. And if plasma
knows this is the use case. If you have no idea the context ever comes back then it doesn't make
sense to keep the shortcuts. We would just clutter the registry.

> looking at the API, plasma-desktop could list all the accels registered for
> "plasma". but with the current API, i run into the same probem that John
> has run into: how to get at the accelerator so that it can be migrated.
> even then, we run into edge cases where the accelerator registered may not
> reference something valid in the plasma-destop layout anymore so we'd have
> to load the desktop and then do the check even if we can get at the
> accels. it's just not pretty. :/

The same answer as i gave John. Tell me an exact use case and i think about it. I sincerely do not
understand what you try to achieve here. So you want to migrate some shortcuts. Why? From? To?

> besides that code, there is the issue of handling accelerators for widgets.
> libplasma does all the management of them and doesn't rely on the central
> bookkeeping at all. as i've explained in the past, this is because there
> are zero guarantees that the objects that are associated with those accels
> will exist on the next run.
> 
> in 4.5 we have the ability to export layouts, for instance. that includes
> the widgets and their global accels, if any.
> 
> one workaround might be to set a unique accel component for each
> Plasma::Containment (assuming that's easily possible) .... but then we
> still have the issue that we have to manually remove all the accels on
> startup for all containments that won't be loaded (esp poignant in the
> case where one containment that will be loaded has a conflicting accel
> with one that doesn't) so again we end up cornered by the "reserve accels
> even if the component isn't registered" policy.

Is this what i described under contexts above? is there any chance i could try this at home?
Could you provide me with a step by step explanation to see this happen? Export something, Import
something, Switch between stuff?

> the implementation that exists in libplasma is, given the design decisions
> in the global accels, the shortest, clearest approach that is effective in
> terms of meeting the needs of an application like plasma.
> 
> i've described this situation to you before on irc and have not received
> any actual solutions. you say you want a document that explains the
> problems so you can think on them further. i suppose this email is as good
> as any.

Believe me. You NEVER described anything in depth. It always was just "kde global shortcut code
does not support plasmas use case", "We want to switch between stuff and ..." and on that level.

Nothing concrete ever. Perhaps it's my problem. But to make me understand you have to use many
words and use cases.

Mike