Right now Plasma shows a popup notification when Yakuake is started. That means this same popup happens upon every log in.
It's a similar situation as BUG 399973. I think we only need notifications when news happens or something is broken. We probably don't need to be reminded every time upon log in that a background app has started perfectly as usual.
I think such notifications has little meaning and they are distracting nuisances. I don't remember this happening on any other systems I used either. Please allow me to suggest we consider not showing a popup message for an "Yakuake" event by default, or only show it once.
Yes I know we can disable it by quickly clicking on the 2nd right-most icon:
[ ] Show a message in a popup
But I think it's not that straight forward for a new user to figure out.
Yeah, makes sense to me.
What makes it worse is that currently that notification seems to be sent with an urgency above low, adding it also to the notification history (https://blog.broulik.de/2019/05/next-generation-plasma-notifications/). So an alarm bell is shown in the tray and clicking it only reveals the Yakuake notification. See attached screenshot.
Originally I was going to propose to set the urgency to low, but since not displaying a notification at all might also be a way, I think I will vote for that instead.
Created attachment 129248 [details]
Entry in notification history
I think the idea behind this notification was to show the user something after they manually started Yakuake. I agree that it makes no sense to show when autostarted. Perhaps we could keep the notification for the manual start use case, or maybe even show the message in the app's main window when manually started instead of using a notification?
I am not sure how Yakuake starts when manually invoked. Maybe it stays in the background, so a notification is needed. At least that happens (most times) for me when it is autostarted.
Is there a way to detect an autostart?
Apart from that I was thinking to lower the urgency of that notification so it is not shown in the history. It might come handy for manual starts, though. Not sure about that.
I also did some search here and found that the startup message was changed to be issued as a notification in https://invent.kde.org/utilities/yakuake/-/commit/ce287f04b76a49cf4c4a9273177bf298be0d6c4a
The relevant program logic has to most likely be implemented here https://invent.kde.org/utilities/yakuake/-/blob/master/app/mainwindow.cpp#L149
I could try to do a merge request, but don't know how to find out whether the program was autostarted. Also I might need help with compiling for manual testing (probably I just need to follow the README instructions).
Not sure if still within the scope of this bug report but I would propose that the default setting of this notification should be off.
And instead we should show a system tray icon with KStatusNotifierItem with for example the following behavior:
- on startup set the status to "active" so it gets shown in the system tray
- after the first retraction change the status to "passive" so it gets now displayed in the extended menu
Having a tray icon would be more consistent with other applications that run in the background (or are not visible to the user) most of the time (e.g. rsibreak). Also it would be great to be able to quit, open and configure yakuake from this icon.
That would also be a very interesting option.
I am not sure though, whether it is useful to completely deactivate the notification, since it informs about the F12 shortcut. But maybe that can be integrated into the tray icon's context menu. To me that seems to be a nice solution.
Would you like to work on an merge request for that?
So I did a implementation if you want to try it out:
That was fast, cool! I might give it a shot tomorrow if I can figure out how to build and install it :)
Should be fixed now with the mentioned merge request.
Thank you Maximilian and Cloudius! Looking forward to see this in action on the next re-install! :D
Just rechecked the merge request that the notification got removed. Since that is the case, I am closing this bug.