When I arrived at Tokamak 6 last week Alex was studying D-Bus communication between various applications. Before I had a chance to really sit down he complained about KWin talking to kded whenever for example a window got moved. This didn’t make much sense, so we had a look at it.
As it turned out that was KWin sending out notifications. Which immediately raised the question of why? Why would a user want a notification that he started/finished moving a window? After all it’s an action the user triggered. What should be done with the notification? Show a message? “You successfully moved a window!”, yes thank you I can see that on the screen. Play an annoying sound? Pling! Hopefully not.
Looking at what KNotify supports only logging to file or running a script make sense in response to the notifications emitted by KWin. But for logging to file it’s rather questionable why one would want that and why one would do that from inside a window manager. So what remains is running a script – fair enough that can be useful.
A closer look to the notifications emitted by KWin showed a few more things. None of them is configured to do something with the notification. By default KNotify just discards the notifications. This means we do a communication with kded via D-Bus for nothing. Two applications are getting woken up, context switches and so on for exactly nothing. Some notifications have a sound file connected to them, but are not configured to play that sound by default. We made a small quiz by me playing the sound file and letting the rest of the group guess what it’s for – I think nobody got one right. Nobody of the core workspace developers knew these sounds.
Looking at the code where the notifications are emitted highlighted another interesting fact. At all places we also emit a Qt signal which is mapped into the KWin scripting environment. And that’s actually quite awesome. Because unlike the notifications it has context. A KWin script does not only get informed about a window that gets moved, but about which window gets moved. Let’s say you are only interested in movements of Firefox windows – with KWin scripting that’s possible, with the notifications it isn’t. Given that we already identified that scripting (and maybe sound) is the only use case for the notifications emitted by KWin it’s getting more questionable why they are still around. Obviously they had been added long before we had KWin scripts. I was unable to really figure out when it got added, as git blame ends in one of the moving around code commits years ago (with more patience one can figure it out, but knowing that it’s old, was enough).
Of course we do not want to break our users’ workflow, so removing the feature is not easy. We have to properly judge whether the users’ workflow is valid enough to penalize all users by the additional overhead in code and in communication especially the context switches. Given that KWin scripting also allows to perform D-Bus calls, it should be possible to rework each of the previously existing notifications in KWin scripts.
That said: in case you were a user of one of those notifications and the removal breaks your workflow: please let me know. Please tell me how you used it and best provide your script. I will have a look at it and try to ensure that it’s still possible with KWin scripting (if it’s simple enough I will just port it).
Hi,
I use sounds for minimizing and maximizing windows. It’s cool 😉
Hello,
the only user case I could think of, would be blind people using a screen reader. So if a certain window e.g. dolphin is activated/startet it would play a certain sound. But I’m not blind myself and have no idea if there are blind people using KDE with e.g. Orca in this way. So please correct me, if I’m wrong
I don’t know how blind people use our desktop, but I doubt that the notifications are a useful mean for it. Again: context is missing. You don’t want to know that “a window got activated”, but that “Firefox got activated”. So if that’s something used for accessibility it should be ported to something more useful.
I’m tempted to say visually impaired users are unlikely to go through the effort to somehow take advantage of these otherwise hidden notifications. The pipework is there but it’s not connected to anything.
I checked the accessibility menus in the control panel, if impaired users were to go anywhere it would have been there; and there’s no mention of window managment.
Odds are these users are using a much more specialised enviornment/OS, I just don’t see users configuring hidden options not even the developers knew about.
My vote is to gut the code, and if it’s ported to a script very clearly label the script as an accessibility feature so it’s understood what it does. Maybe add a toggle in the accessibility menu to enable it – if the script is detected.
atspi, the Linux a11y stack, allows this already including ways to fetch/inspect context like Window size, states, widgets within that window, etc. No need for that from an a11y-stack view imho.
obligatory xkcd: http://xkcd.com/1172/
Imho it’s a good idea to remove these notifications.
oh, you already linked xkcd 🙂
That’s the link behind “workflow” in the blog post 🙂
Sounds like an excellent way to drive your co-workers insane.
FWIW, I use sounds for minimizing/restoring windows too, and also, for start moving/finish moving. I like having the option 🙂
I always thought it would be kind of cool to have a sound theme that mimicked the window sounds in UFO: Enemy Unknown. It would have to handle button presses as well though and I suspect it would be more annoying than cool after a short time.
Maybe KNotify should check if the server will have something to do before sending it over DBus?
If we could do that all apps that send notifications which end up not being used would benefit, what do you think?
there’s discussion about making knotify only a library instead of using a kded. But I don’t know any details.
Are any of these notifications related to the kwin effects ?
Will any kwin effect be affected by this ? like cover switch or open and close animation ?
If i am interpreting it wrong , than kill it away. If it can be done by scripting better.
Now .. we should do something with the scripting … something that even a normal non-javascript coder could do.
Ps: i hope that “Benachrichtige mich über nachfolgende Kommentare via E-Mail.” means send reply notifications by email 🙂
“Ps: i hope that “Benachrichtige mich über nachfolgende Kommentare via E-Mail.” means send reply notifications by email”
Indeed, that’s what it means. You will get notifications, but only to replies to your posting. It’s a bit curious that the button (“Post Comment”) and the entire top section “Leave a Reply,” etc. are translated, while the two strings at the bottom are German. You’d think WordPress does this better.
Sune Vuorela had plans to eliminate knotifyd and turn it into an in-process library to avoid the D-Bus chatter for KF5. That would also help apps like Konversation (we have to send every frigging message over the bus).
I can’t even think of any usecase for sounds when my window is moving except to annoy somebody in the same room.
Example situation where you want to give a senior audio feedback of window moving starting and ending with smooth audio (not any of those “PING BLING CLING TATTARAA!”).
The usecases are very limited, but at least they help for first few weeks/months.
is that really a valid use case given that we have visual feedback?
oh and how exactly would the senior configure these smooth audio notifications? If it’s not default a senior would not find it.
It could be configured by its grandchildren.
“Why would a user want a notification that he started/finished moving a window? After all it’s an action the user triggered.”
Not always, KWin rules are such ones what allows pre-configured rules to move the window.
And what others said, people with vision problems or sound effects (what are great for seniors and kids who have great sight but just to give audio feedback) etc.
Still, it should be so that only if user pre-configure rules or user enables usability features, notifications should be started to be made. Otherwise keep them turned off.
I don’t think that case triggered the notification, but even if it would be the case of missing context. KWin scripting is better suited for that (which knows whether a user or the system is moving the window).
When I was younger, I used to have sounds to many actions of the windows. I liked the feedback it gives.
You’re saying it is not possible to be interested only in the action of the firefox window with notification. But there is the concept of notification context which is meant to allow exactly that. (Ok, it may be hard to configure)
at least the notifications sent by KWin to knotify had no context at all.
I’m not a developper and this is a bit of a brainsotorm, right? So, using a bit of empathy and putting my self in the role of a developper in the “old early” days of the kde4 developpement, I would want to have everything logged for a proper troubleshooting and while implementing those communications and logs, one way to test its implementation would be to have a sound feedback telling me the communication and the log was correctly produced, instead of having to open a log file.
If you want to be sure not to embarrass anybody–couldn’t you simply deploy a KWin-script sending exactly the same DBus-messages (disabled by default)? That should not be very hard to implement. You could even check whether there are such notifications configured and in that case inform the user that he has to activate the script, but I guess that would not be necessary (because few users use it).