Summary: | Need help troubleshooting badge counter notifications in latte-dock. | ||
---|---|---|---|
Product: | [Unmaintained] lattedock | Reporter: | Jonathan Chun <unmonitored> |
Component: | application | Assignee: | Michail Vourlakos <mvourlakos> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | shawnk723 |
Priority: | NOR | ||
Version First Reported In: | git (master) | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Jonathan Chun
2020-04-05 05:54:24 UTC
Latte supports the same apis that plasma taskmanagers already support, that is the Unity api and the knotifications one. For all other cases has introduced also a Latte specific dbus call that someone can use directly to send badges information Latte supports the same apis that plasma taskmanagers already support, that is the Unity api and the knotifications one. For all other cases has introduced also a Latte specific dbus call that someone can use directly to send badges information (In reply to Michail Vourlakos from comment #2) > Latte supports the same apis that plasma taskmanagers already support, that > is the Unity api and the knotifications one. Any ideas on why Discord/Mailspring don't work in Latte if it supports the same Unity Launcher APIs that's being used in ubuntu-dock (Ubuntu 18.04/20.04). I saw some chatter about how the .desktop file needed to be named correctly and how at least in Plank, it looks for a very specific .desktop file naming convention or something. Is there any restrictions like that within Latte? Mostly referring to comments like this one: https://github.com/Foundry376/Mailspring/issues/420#issuecomment-441687528 https://github.com/KDE/plasma-desktop/blob/master/applets/taskmanager/plugin/smartlaunchers/smartlauncherbackend.cpp This is Plasma and Latte implementation for Unity protocol, take a look 1. The applications that fail where to they install their desktop file? 2. If you pin them as launchers in the taskmanager are they associated correctly with their windows? (In reply to Michail Vourlakos from comment #5) > 1. The applications that fail where to they install their desktop file? > 2. If you pin them as launchers in the taskmanager are they associated > correctly with their windows? The applications are installed in /usr/share/applications. Yes, they are correctly associated with their windows and I can add to favorites/launch/etc. They all have their proper StartupWMClass set. I'll see if I can find time to dig into the implementation you linked and try and figure out what's different. I only opened the ticket here against latte dock because my initial reaction when 2 applications work in Ubuntu 18/20 but don't work in the KDE version when they're using the same Unity Launcher API is that perhaps the implementation here is different/more strict than whatever's being used in ubuntu-dock. dont worry, if you track it down and you find out that the plasma is not supporting Unity protocol correctly then it is good to know the reason in order to inform plasma devs to fix it and thus both plasma taskmanagers and Latte will be fixed immediately. I am not familiar enough with C++ to know how to test my theory, but I think you can rest assured that this is not a latte-dock problem. I suspect it is an issue upstream with Electron. I'm not 100% sure where it's failing, but my guess is that in the KDE environment, this function here where it is looking for the desktop file is returning the wrong value. https://github.com/electron/electron/blob/b6246dcf122e584c672566877cb60d33dbc4705e/shell/browser/linux/unity_service.cc#L90 I was able to get badge counters (albeit fake numbers) to show up on the apps in question (Mailspring/Discord), both of which use electron with a quick python script to check the unity launcher api, Both libunity and straight through dbus work fine with a quick python script: https://paste.ubuntu.com/25473314/ https://paste.ubuntu.com/25615125/ I got the snippets from https://github.com/micheleg/dash-to-dock/pull/590 from the guy who wrote the unity launcher feature for dash to dock, so fairly certain that it's up to spec with the Unity Launcher API. I get "true" if i console.log IsUnityRunning(), so it's not being blocked by the fact that I'm running KDE. https://github.com/electron/electron/blob/b6246dcf122e584c672566877cb60d33dbc4705e/shell/browser/linux/unity_service.cc#L118 Here, we can see that KDE4/KDE5 are considered valid unity environments: https://github.com/electron/electron/blob/b6246dcf122e584c672566877cb60d33dbc4705e/shell/browser/linux/unity_service.cc#L65 ----- Mostly just documenting this stuff here so that if someone comes across it in the future, they can at least see what I tried. I'll do a little bit more testing and probably open an issue with Electron for further troubleshooting assistance, so I think we can close it out here on the KDE side if you agree. I can circle back here with a new ticket if I get anything more concrete pointing at lattedock. Update. After going crazy and testing a bunch of stuff out, I wasn't able to figure out what the problem was because everything looked OK. Then... it magically fixed itself after I started playing around with Python's libunity bindings/dbus/building my own electron app to see if I can reproduce it, I noticed the badge counters were working perfectly! Extremely confused, I went back and looked through to see where I went wrong(right?). Turns out, you need to: sudo apt-get install libunity-dev on Kubuntu/KDE Neon. I had previously thought that I might have been missing libunity on my system, so I did apt search libunity This gave me a TON of results, a lot of which I already had installed such as libunity-protocol-private0, libunity-core-6.0-9, libunity9, so I mistakenly assumed I was OK on that front. Who would have guessed that libunity-dev is required as well... In any case, I've marked this resolved. There are still other issues with the unity launcher API only working with specifically named files and flatpak/snapstore/etc changing it and breaking compatibility, but thanks to all the effort I put into troubleshooting this, I think I have an idea of how to resolve that as well. Thank you for your patience Michail! ----- One thing to consider. I don't know what the standard is for apt dependencies, but if a major feature like unity launcher API doesn't work without the libunity-dev package, perhaps it should either 1. be documented in FAQ, or 2. added to the package requirements? Depends: plasma-desktop, plasma-pa, plasma-workspace (>= 4:5.9.0~), libc6 (>= 2.14), libkf5activities5, libkf5archive5, libkf5configcore5, libkf5configgui5, libkf5coreaddons5, libkf5crash5, libkf5dbusaddons5, libkf5declarative5, libkf5globalaccel5, libkf5guiaddons5, libkf5i18n5, libkf5iconthemes5, libkf5newstuff5, libkf5notifications5, libkf5package5, libkf5plasma5, libkf5plasmaquick5, libkf5quickaddons5, libkf5service5, libkf5waylandclient5, libkf5windowsystem5, libkf5xmlgui5, libqt5core5a (>= 5.14.1+dfsg), libqt5dbus5 (>= 5.14.1+dfsg), libqt5gui5 (>= 5.14.1+dfsg), libqt5qml5 (>= 5.14.1), libqt5quick5 (>= 5.14.1), libqt5widgets5 (>= 5.14.1+dfsg), libqt5x11extras5, libstdc++6 (>= 5), libx11-6, libxcb-randr0, libxcb1 Please you can do both 1. Is a wiki, and you can add that information, https://userbase.kde.org/LatteDock/FAQ 2. The INSTALLATION.md file is totally community driven and I accept any updates immediately (In reply to Jonathan Chun from comment #9) > Update. After going crazy and testing a bunch of stuff out, I wasn't able to > figure out what the problem was because everything looked OK. > > Then... it magically fixed itself after I started playing around with > Python's libunity bindings/dbus/building my own electron app to see if I can > reproduce it, I noticed the badge counters were working perfectly! Extremely > confused, I went back and looked through to see where I went wrong(right?). > > Turns out, you need to: > sudo apt-get install libunity-dev > > on Kubuntu/KDE Neon. I had previously thought that I might have been missing > libunity on my system, so I did > apt search libunity > > This gave me a TON of results, a lot of which I already had installed such > as libunity-protocol-private0, libunity-core-6.0-9, libunity9, so I > mistakenly assumed I was OK on that front. Who would have guessed that > libunity-dev is required as well... > > In any case, I've marked this resolved. There are still other issues with > the unity launcher API only working with specifically named files and > flatpak/snapstore/etc changing it and breaking compatibility, but thanks to > all the effort I put into troubleshooting this, I think I have an idea of > how to resolve that as well. > > Thank you for your patience Michail! > > ----- > > One thing to consider. I don't know what the standard is for apt > dependencies, but if a major feature like unity launcher API doesn't work > without the libunity-dev package, perhaps it should either 1. be documented > in FAQ, or 2. added to the package requirements? > > Depends: plasma-desktop, plasma-pa, plasma-workspace (>= 4:5.9.0~), libc6 > (>= 2.14), libkf5activities5, libkf5archive5, libkf5configcore5, > libkf5configgui5, libkf5coreaddons5, libkf5crash5, libkf5dbusaddons5, > libkf5declarative5, libkf5globalaccel5, libkf5guiaddons5, libkf5i18n5, > libkf5iconthemes5, libkf5newstuff5, libkf5notifications5, libkf5package5, > libkf5plasma5, libkf5plasmaquick5, libkf5quickaddons5, libkf5service5, > libkf5waylandclient5, libkf5windowsystem5, libkf5xmlgui5, libqt5core5a (>= > 5.14.1+dfsg), libqt5dbus5 (>= 5.14.1+dfsg), libqt5gui5 (>= 5.14.1+dfsg), > libqt5qml5 (>= 5.14.1), libqt5quick5 (>= 5.14.1), libqt5widgets5 (>= > 5.14.1+dfsg), libqt5x11extras5, libstdc++6 (>= 5), libx11-6, libxcb-randr0, > libxcb1 this problem still exists on Arch and installing libunity doesn't work any more. |