Created attachment 118269 [details]
screenshot 1 (bug)

Created attachment 118270 [details]
screenshot 2 (expected)

Sorry I forgot one step for reproduce:
4. Create a notification with your favorite terminal `$ kdialog --passivepopup 'This is a notification' 10`

I just found out that even when I don't add it to startup and just start kde without any control bar the notifications are useless text boxes at position (0,0). When I then start latte-dock they remain useless text boxes. Only when I replaces the first running instance with a second one - then I get the correct notification look and feel.

strange that is not the behavior in my system. It makes sense to have that problem when not Latte is running but when is loaded afterwards with systray or notifications applets then all the upcoming notifications should be shown correctly.

On my notebook (with kde neon) it works out of the box (Plasma: 5.15.1; Framework: 5.55.0; Qt 5.12.0). Maybe to add that I installed Manjaro Gnome on my desktop and switched to KDE later. It was quite a mess to get everything to work (e. g. kwallet). Maybe the ordering of stratup is messed up in ssdm. But anway the app should try to register to the notification service again if it didn't work at the first place. Unfortunately I have no idea how this works and if there is a response like "failed to register knotify"...

I've now disabled the startup and run it in a terminal with --debug and this is what I get during start:

[warning 6:51:53.4242] - couldn't load "/usr/lib/qt/plugins/discover-notifier/DiscoverPackageKitNotifier.so" because "Die Bibliothek /usr/lib/qt/plugins/discover-notifier/DiscoverPackageKitNotifier.so kann nicht geladen werden: (libpackagekitqt5.so.1: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden)"
[warning 6:51:53.421421] - couldn't load "/usr/lib/qt/plugins/discover-notifier/FlatpakNotifier.so" because "Die Bibliothek /usr/lib/qt/plugins/discover-notifier/FlatpakNotifier.so kann nicht geladen werden: (libflatpak.so.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden)"
[warning 6:51:53.421421] - couldn't find any notifier backend ("/usr/lib/qt/plugins", "/usr/bin")
[info 6:51:53.476476] - Failed to register Notifications service

Created attachment 118369 [details]
debug log

I resolved the two warnings by installing two packages but still the the log shows "Failed to register Notifications service" in the first run but not in the second run. I've no idea what happens - is there more debugging output I can provide?

Do you have any other plasma panel running?

or the Gnome case may have leave something behind

Sounds like a conflict between knotify and the gnome's one that prevent knotify starting. Similar question: https://www.reddit.com/r/kde/comments/81hw4s/knotify_conflict_with_ubuntus_notifyosd/

Try to find and disable it.

I found out that I can solve the problem when I modify the yakuake autostart with
Exec=sh -c 'sleep 3; yakuake'

The question remains: why latte can't register the notifications service?

Hint: yakuake shows a notification on start.

(In reply to Thomas from comment #11)
> I found out that I can solve the problem when I modify the yakuake autostart
> with
> Exec=sh -c 'sleep 3; yakuake'
> 
> The question remains: why latte can't register the notifications service?
> 
> Hint: yakuake shows a notification on start.

yeah , yakuake was starting before Latte and for that reason the notifications appeared broken. 

Unfortunately I dont know any way in order to set priority for autostarts

Now with a new KDE-Plasma Version it is finally broken: what means that even a `latte-dock --replace` doesn't solve the problem.

Operating System: Manjaro Linux 
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59.0
Qt Version: 5.13.0
Kernel Version: 4.14.109-1-MANJARO
OS Type: 64-bit

I don't think it is resolved. Maybe it is a dbus issue instead of a latte-dock issue?

I've now taken a look in the dbus-monitor and found the following:

method call time=1563260861.224737 sender=:1.182 -> destination=org.freedesktop.DBus serial=567 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
   string "org.freedesktop.Notifications"
   uint32 5
method return time=1563260861.224750 sender=org.freedesktop.DBus -> destination=:1.182 serial=60 reply_serial=567
   uint32 3

Why are you call it with `DBUS_NAME_FLAG_ALLOW_REPLACEMENT` but not with `DBUS_NAME_FLAG_REPLACE_EXISTING`? Or may I configure it somewhere?

The answer is `DBUS_REQUEST_NAME_REPLY_EXISTS` I don't know yet how to check who is registered there...

I found out it is dunst required for update-notifier required for gnome-shell-extension-manjaro-update. Ok there are several questions here but they don't belong to latte-dock (for example: why dunst starts when I'm not in gnome)

But anyway: I don't know if DBUS_NAME_FLAG_REPLACE_EXISTING will solve it but it should at least try to replace the existing notification service.

Has been fixed I think from Plasma 5.16 new notifications system. The issue I think was that if notifications service started too early it was creating unthemed notifications

As said: I'm on plasma 5.16 and it is not fixed. It was dunst that was registered as notifications service and latte-dock didn't tried to replace the existing - maybe it should.

Latte-Dock Version: 0.8.9

My opinion as long as you have some tech expertise is too open up a new issue in plasma shell for notifications system. The maintainer is kbroulik which is pretty active solving issues for the new notifications system. And afterwards let's make this bug as upstream of the new plasmashell issue... I will follow the discussion from. there in order to contribute

(In reply to Thomas from comment #16)
> As said: I'm on plasma 5.16 and it is not fixed. It was dunst that was
> registered as notifications service and latte-dock didn't tried to replace
> the existing - maybe it should.
> 
> Latte-Dock Version: 0.8.9

Latte can not replace the existing of Plasma notifications service. Plasma has higher priority!! Do you have any systray or Plasma taskmanager or notifications plasmoid in a plasma panel or Plasma desktop??

about which plasma version you are talking? I'm using 5.16 and there is no plasma notification service registered in dbus. i don't have any plasma panel.

https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-request-name
says that you can provide 0x2 flag to try to replace the existing notification service. as shown in the dbus-monitor you are just sending 0x1 and 0x4 (don't queue and deny replacement).

Sure when there is still an issue with notifications in a new plasma version it should be solved there.

(In reply to Thomas from comment #19)
> about which plasma version you are talking?

5.16

I will forward this to plasmashell to get more feedback...

Do you have "dunst" installed?

Ah, yeah, you do. Uninstall dunst. Problem solved?

It is intentional and not going to change that plasmashell has the highest priority for notification service ownership. Otherwise we'll get a race between Latte and plasmashell instead: Latte dock starts, registers notification and job tracking service, then plasmashell comes up and fails to claim the service resulting in a broken user experience. Something that happened quite often in 5.16.x.

> Uninstall dunst. Problem solved?

Yes, it is solved now for me.

When I understand you correct it means that plasma registers first (when I have a notification widget or a plasma panel?) and should not be replaced by another service? plasma can register without `DBUS_NAME_FLAG_ALLOW_REPLACEMENT` and latte can still try to replace with `DBUS_NAME_FLAG_REPLACE_EXISTING`. when plasma is already registered it fails...

To make it clear my question is: why is latte-dock not using `DBUS_NAME_FLAG_REPLACE_EXISTING`?

> why is latte-dock not using `DBUS_NAME_FLAG_REPLACE_EXISTING`?

To not cause Bug 408250

but when plasmashell registers without `DBUS_NAME_FLAG_ALLOW_REPLACEMENT` it will not be replaced anyway and another service that allows replacement can be replaced by plasmashell or latte-dock. at least that is what I understood from dbus manual

Latte dock and plasmashell use the same library for notification and job tracking. What happened is:
User logs in, latte dock and plasmashell start. Latte dock is quicker and registers the services. Then plasmashell gets to the point where it tries to register the services and fails. And then you end up with the bug I mentioned.

Latte uses job tracking service without providing a full UI for it, so having job tracking service owned by Latte when you have notification plasmoid in plasmashell instead results in no job dialog being available to applications. It's difficult to explain. Feel free to submit a patch using whatever behavior you think is best but making sure not to regress any of the bugs I fixed by changing the registration behavior.

ah! now I understand. So the interface of the library, both are using, does not support to overwrite the flags?

Thanks, but I'm afraid it's not my programming language and I've not enough experience to hack a widely used library from kde :)