Finding shortcut

[Aaron J. Seigo]

On January 31, 2010, Michael Jansen wrote:
> > you and i both know that we disagree quite strongly about other matters
> > related to global shortcuts, matters which cause usability problems for
> > plasma-desktop (and other apps, i imagine) which we therefore work around
> > in our application code but which you have your own reasons for having
> > implemented them as you have.
> 
> And i told you uncountable times i did not implement or design that stuff.

that's fair enough; it is also true that it is currently your decision to 
stick to those design decisions. 

in the discussions you and i have had, you've defended (with reasons) why 
global shortcuts should remain registered even if the app no longer is running 
and why the decisions surrounding the lifespan of the global shortcuts should 
be not in the application itself. i disagree with that, and have my reasons 
for that, which i've shared with you. so, we disagree. *shrug* 

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. i really 
don't care if it doesn't mesh with the intended design of global accels if 
that design does not cover the needs of applications.

again, we disagree on that. so be it.

> And i asked uncountable times to write down your problems with the way
> global shortcuts are currently implemented so we all can take a real look
> and think how to solve it.
> 
> Something the plasma team still failed to provide.

given our conversations on irc, i have no reason to believe that there will be 
any adjustments made if i create a transcription of what i've said on irc and 
send it to you as a file. but it's a moot point now: this email describes the 
issues.
 
> Instead i again and again just get complains and then sarcasm and then

i haven't complained about the life spans of global accels since our last and, 
imho, conclusive conversation on the matter. the last time i've said 
_anything_ about global accels was in the conversation about whether they 
should show popup notifications by default and about the API to get the key 
sequence associated with a global accel. neither has to do with the issue that 
you and i disagree on, which is accel lifespan management.

> people getting totally of having fun ending in some totally off-target
> solution from your side (
> kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp:111 ) that is
> especially made to ridicule the global shortcuts stuff and doesn't help.

that lengthy comment is actually there to explain precisely what that line of 
code does. the only sarcasm in it is this:

"
    // this line should be removed when we decide that 4.[012]->4.<current> is
    // no longer a supported upgrade path. sometime after dragons make a 
comeback
    // and can be seen circling the skies again.
"

and that has nothing to do with global accels and everything to do with how 
long we have to maintain version-to-version upgrade capabilities. e.g. an 
upgrade from 4.2 -> 4.10 (or whatever) is probably going to be seen as valid, 
which means we have to preserve whatever code is there to support such a 
thing. my biggest concern about that workaround is that someone will see it in 
3-4 years while doing janitorial maintenance and go "huh, it hasn't been 
called 'plasma' for a looong time, that can't be relevant anymore!" and remove 
it. unfortunately, the explanation for why it's needed is really quite long.

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.

> Which is always the time i stop caring. I helped amarok, kwin, krusader
> and some other to solve their/some global shortcuts problem. The only team
> unable to accept that help is yours.

given how many times i've actually had this conversation with you, very calmly 
even, this rings all the wrong bells for me. here is a re-cap of what i've 
communicated in the past:

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.

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.

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

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

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.

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.

> Btw. Thanks for the explanation about naming conventions. I appreciate your
> work on kde and the way you seem to want to help everyone. But you have to
> understand im tired of your behaviour in that particular regard. So stop
> it and help solve the problems instead of always bringing up the same old
> complains ("Re: KGlobalAccel Notifications").

you mean the observation that it sends other notifications that are never seen 
except during debugging? that related directly to the topic of notification 
usage there and is something that i don't think many of us working on 
infrastructure bits in KDE are aware of. just as with the popup notifications, 
it's an implementation decision (not a design decision in this case :) that 
has been made which affects all of KDE. i think that when we're discussing 
notifications and kglobalaccel, that's very on-topic and relevant.

honestly, if i was packaging up KDE and wanted to deliver something with good 
performance, removing those notifications is one of the patches i'd ship. and 
i think that sucks because i personally -hate- it when we lose diagnostic 
tools because downstream tweaks something. i really think that if a way to 
debug accel issues is needed, we should find a different means. or maybe the 
kglobalaccel code that was new in 4.0 is well tested enough by now that those 
notification aren't warranted anymore.

and yes, i'm not personally satisfied with "it occasionally helps me debug 
things" as an answer to "this is only useful for debugging and interferes with 
runtime performance even on no-debug builds".

imho, it should be wrapped in a #ifndef NODEBUG, though i don't know if that's 
acceptable to you as it seems to be a way to work around not being able to get 
information out systems running with debug-less builds. *shrug*

if you want to continue this part of the discussion, let's do it in the 
appropriate thread.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks