KGlobalAccel notifications

[Michael Jansen]

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

Your wish is my command :))

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

We have many of those. But you ask the wrong question and blame the wrong code. If i want to add a 
notification i should be able to just do it. If i have to ask myself always and everytime if it is a 
good idea and does it affect performance the framework has to be improved.

So now to the real problem. Why does application x even send something over dbus if noone is 
listening? Why doesn't the server (knotify?)  inform application x that noone is listening and to 
just not bother with that event?

If we improve the notification code that way we will improve the performance for many users. Just 
removing one notification because for some unknown reason you think it hinders the performance won't 
really help.

And my solution probably helps with battery live not to wake up other apps if not needed. Not just 
in this particular case.

Btw. because you again talked about it i see one thing i can improve. I was sure i did it the first 
time that way but my memory failed. I will switch the order. It currently is wrong. First the 
notification, then the app is informed about the pressed shortcut. I will change the order and 
backport.

And another btw. If you want to improve kglobaccels performance there is much lower hanging fruit. 
Currently if a global shortcut is pressed the applications are informed by broadcast. That's right 
pressing a global shortcut wakes up EVERY application on the bus. all applications but one go back 
to sleep because they are not interested in that particular event.

All people knowing of the problem expect me to fix it. And there are some people that expect things 
from me that pay me. That's why they win in the fight about my ressources.

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

We have many problem because the (global) shortcuts code is a difficult beast. The reasons are:

1. Qt does not support global shortcuts. That's why we have our own solution.
2. Qt has it's own Key handling code. It's own idea what values represent which modifiers and keys. 
That's because they have to support more than unix. And qt's values have to be mapped to x11 values.
3. Qt does not provide any method to map the x11 key values into it's own system. That's why we have 
the KKeyServer class which does the mapping for us. The idea is to do it the same as qt does but it 
fails because this is a pretty difficult thing.
4. That's why we have many problems with not working globalshortcut when using 'Meta+"' or others 
(167428 for example).

The same applies in parts to the normal shortcut code. KKeySequenceWidget for example seems to not 
always end up with the right value. But i can't really grasp that problem.

So to your mature theory i make a bold statement. That code will never be mature enough to be 
considered bugfree unless we have a way to get rid of classes like KKeyServer and KModifierInfo and 
work completly with qt code.

Btw. I had a look at making a patch for qt to provide that methods but i failed. That code is pretty 
difficult and even if i could get a patch up it probably would get rejected because i would only 
implement one platform and qt needs all X of them. If they reject bugfixes with that reason i will 
not even try with a feature.

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

Then complain about the correct code. Notifications is a feature kde provided. If i use it and if 
someone thinks it is bad for the performance then fix the notification code. I'm just using the 
feature.

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

That's the idea behind it. I can get information from people that run distribution packages.

Mike