Notification popups look and act different in Plasma Wayland

[Havin_it]

Hi,

I just took my occasional spin on the Plasma Wayland session and apart from the well-known papercuts (and some new ways of triggering a crash bug I've been getting in X11 by different means) it's looking and acting pretty consistent.

One exception: systray notification popups (seen from kdeconnect, possibly other sources, don't recall).

On X11 these are themed, with top-bar and Close button, appear just above the systray, show a countdown-bar animation and then disappear.

On Wayland, they are primitive white-on-dark-grey text-boxes that appear at top-right of the screen and are only dismissed by clicking them or by negating them at source (e.g. clearing the notification from my phone or from kdeconnect's plasmoid menu).

Is this expected? The appearance and behaviour is so different it makes me wonder if I've got a flag or package missing somewhere.

[rab0171610]

I am not able to replicate this issue. To be clear (in both Plasma Wayland and X sessions), all of my notifications for system, apps like Thunderbird emails, and KDE Connect messages from my phone all show up under the notifications menu in the KDE system tray and I am able to close them individually or in groups by clicking the X in the top right corner of each message or group of messages.

I would set up a new user and try to see if the issue is replicated. If it is, then this eliminates personalization and configuration issues like misbehaving plasmoids, themes, etc.

If you still have issues it might help to see your make.conf.

Did you install plasma as the default all purpose kde-plasma/plasma-meta?

What is your graphics setup, driver etc?

It sometimes helps with these kinds of theme issues to delete (or temporarily move) the files in cache from the command line when not logged in to a KDE session. This can be done in a TTY when the SDDM login screen is displayed. This is generally harmless and the files should be recreated on login. You can check to see if it made any difference after logging in again.

In order to do this last option, you would need to have kde-plasma/plasma-sdk installed.
Since the system tray and the notifications service, specifically KDE's Status Notifier Manager, is already running and connected to DBUS, trying to run a second instance will fail and it will only give you limited information but you can try it anyway to see if there is any helpful output.
From the terminal, you can run:

Code: Select all

plasmoidviewer -a org.kde.plasma.notifications 

and

Code: Select all

 plasmoidviewer --applet org.kde.plasma.systemtray 

to see if there is any helpful messages or output.
From the last one, you can click on the notifications icon in the system tray and observe the output in the terminal. If the notifications icon is not visible it may be hidden and you would need to click on the arrow for "show hidden icons" in the system tray to access it.

[Havin_it]

Hi, thanks for the detailed advice. Turns out the explanation is a bit more prosaic, and jumped out at me once I happened to look in System Settings > Notifications.

Notifications are currently provided by 'emersion mako' instead of Plasma.

I installed gui-apps/mako for use with other Wayland compositors. I just need to figure out why it is being started in the Plasma session as well, and how to prevent that.

[rab0171610]

Hey, prosaic is good. I will take the mundane and dull explanations over the cryptic and elusive any day.
After some reading I see that having other notification services has been known to conflict with KDE's own notification system.
I can't verify this but users online have indicated that creating a local symlink to the system org.kde.plasma.Notifications.service file will prioritize KDE's notification system over others:

Code: Select all

mkdir -p ~/.local/share/dbus-1/services/
ln -s /usr/share/dbus-1/services/org.kde.plasma.Notifications.service   ~/.local/share/dbus-1/services/org.kde.plasma.Notifications.service

https://unix.stackexchange.com/question ... kde-plasma
https://old.reddit.com/r/kde/comments/k ... yland_for/

[Havin_it]

That solves the issue perfectly for KDE, thanks.

As it is a "global" (not DE-specific) config, I wonder if this would have any converse knock-on to the other compositor sessions? (I'll come back and answer this, no time just now.)

I am not at all versed on this new era of dbus-triggered services but I surmise that there must be other similar situations where there might be multiple (DE-specific or otherwise differentiated) apps that provide the same services and therefore have trouble coexisting in a single heterogeneous system. Are there standard ways in such scenarios for the user to prefer one over another based on context (envvars or whatnot)?

[Havin_it]

To answer my own question above:

Nope.

On the well-known session bus, if two .service files in the same directory offer the same service name, the result is undefined. Distributors should avoid this situation, for instance by naming session services' .service files according to their service name.

So dbus spec expects us not to have two apps installed that offer the same service. Someone must alert Gentoo maintainers immediately! Mako and KDE must not be co-installable!

An approach to resolving this very conundrum here.

[Havin_it]

So in fact it turns out that Mako is not even needed in the case of Wayfire or labwc, at least not if you are using them with a panel/dock that provides a tray implementation (I'm using wf-shell and sfwbar respectively). I first disabled mako from their autostart configs, then unmerged it altogether, and they both receive notifications sent via notify-send (although in labwc+sfwbar's case they do not pop up automatically).

Oddly, the notification flyout looks exactly the same in both compositors/panels. Is it actually shared, or just duplicated? Can it even be that what I'm seeing is actually furnished from KDE?

I'm down a rabbit hole now and must learn more