Even though qdbusviewer says org.bluez is registered at system bus. But qdbus says: qdbus-qt5 | grep blue org.bluez.obex Reproducible: Always
The command would be qdbus-qt5 --system | grep blue. I assume the bug report is for current master, right? Can you please check applets in sys tray settings?
Created attachment 91887 [details] screenshot The applet is shown as autoloaded, but not started. Yes, this is with master. And yep, sorry, the system bus has: qdbus-qt5 --system | grep blue org.bluez
You need to enable it with the checkbox :)
Right =) But i wonder if the idea is that the applet is disabled by default? At least according to X-Plasma-DBusActivationService, it should magically load when the wanted DBus service turns up. This is working like that with networkmanagement and mediacontroller applets.
Yes, that's right, the applet will only be loaded when org.bluez is registered. But you still have an option to disable it (which seems you did), because it should be enabled by default: X-KDE-PluginInfo-EnabledByDefault=true
So this is a side-effect of commit 5196689ae328decf7865e053d3e5997c2c184b16 in plasma-workspace. For existing users the applet is not automatically added, for clean/non-existing config it's working as expected, i.e. the applet is there.
We really need that to reparse and keep a proper white and blacklist not just set a default.
yes, the idea is that the configuration for existing setups doesn't get changed. a solution may be having a blacklist of those that you don't want instead of a whitelist would be quite a behavior change between versions tough
(In reply to Marco Martin from comment #8) > yes, the idea is that the configuration for existing setups doesn't get > changed. even though i understand the reasoning, i don't quite agree =) if a user installs a new applet, i think he would expect it to turn up in the tray without manual enabling. for bluetooth applet it is even more different. 5.2.x user had e.g. bluedevil-monolithic which was shown in the tray. he upgrades to 5.3.x -> the applet is gone. user should only notice the behaviour on icon click is different (menu vs. applet), but he IMHO shouldn't need to go through the systray configuration and try to discover what he needs to enable...
one way may be to save in the config also a list of all known applets, so a new one would be added * if is enabledByDefault and * if is not in the list of known ones
https://git.reviewboard.kde.org/r/123789/
Git commit b494fe13770f25058179f93ab7cf355517078166 by Marco Martin. Committed on 14/05/2015 at 15:17. Pushed by mart into branch 'master'. automatic add new installed plasmoids in systray if new plasmoids are installed that are systray enabled and enabled by default, automatically add them, unless they were disabled explicitly. This solves a problem distributions seem to add while updating to new plasma releases. obtain this by keeping both a list of explicitly enabled stuff and all the already known stuff REVIEW:123789 M +6 -3 applets/systemtray/package/contents/config/main.xml M +32 -9 applets/systemtray/package/contents/ui/main.qml http://commits.kde.org/plasma-workspace/b494fe13770f25058179f93ab7cf355517078166
Git commit bc76c7143e82fc1311f7fe2048e62ec0f43451b9 by Lukáš Tinkl, on behalf of Marco Martin. Committed on 15/05/2015 at 00:54. Pushed by lukas into branch 'ltinkl/solid-power'. automatic add new installed plasmoids in systray if new plasmoids are installed that are systray enabled and enabled by default, automatically add them, unless they were disabled explicitly. This solves a problem distributions seem to add while updating to new plasma releases. obtain this by keeping both a list of explicitly enabled stuff and all the already known stuff REVIEW:123789 M +6 -3 applets/systemtray/package/contents/config/main.xml M +32 -9 applets/systemtray/package/contents/ui/main.qml http://commits.kde.org/plasma-workspace/bc76c7143e82fc1311f7fe2048e62ec0f43451b9