Not going to work. Most likely.
First of all, this stuff is super difficult to test and debug. Full explanation:
kde settings files / packages - debugging and changeing user settings as a distribution
Shipping plasma-desktop-appletsrc didn’t work in wheezy. Would be surprised if it works now. Just try and/or research. The answer was, that one has to use javascript magic.
Most likely similar to the previous javascript solution:
From more looking around it seems to be the only way to configure desktop widgets:
Its a small detail lets just forget it. Not worth the debug hassle you describe. I’m surprised no one on the KDE list wrote back.
[quote=“HulaHoop, post:22, topic:507”]From more looking around it seems to be the only way to configure desktop widgets:
That doesn’t work either. File ~/.kde/share/config/plasma-desktop-appletsrc doesn’t exist at build time, because there has never been a login to kdm. And at login time, the network-manager systray is created with KDE and/or Debian defaults. Instructions such as “log in”, “log out” work for users, but not for a distribution.
I see. Will this other solution be any good?
I don’t see how.
Overview how kde service/applets startup works and the options users have to customize them:
blog.davidedmundson.co.uk/node/8
EDIT:
I misread. The “right way” is different from the way to do things that what I’ve seen before.
Which file is responsible for starting the network management systray icon? Some [font=courier].desktop[/font] file? If the systray no longer autostarts by default by deleting that file - something to test - then we could use config-package-dev’s hide or displace operation to get rid of that file.
Seems like deletion of [font=courier]/usr/share/kde4/services/plasma-applet-networkmanagement.desktop[/font] gets rid of that systray icon. But then how could a user undo this and start the systray icon?
http://blog.davidedmundson.co.uk/node/8 might or might not apply here. Maybe getting rid of services located in [font=courier]/usr/share/autostart[/font] by adding an override to [font=courier]/etc/xdg/autostart[/font] would be a clean solution. But is there a mechanism to overrule files located in [font=courier]/usr/share/kde4/services/[/font]?
[hr]
package:
https://packages.debian.org/jessie/plasma-nm
file list:
apt-file list plasma-nmWhich file is responsible for starting the network management systray icon? Some .desktop file?
Likely: /usr/share/kde4/services/plasma-applet-networkmanagement.desktop
http://blog.davidedmundson.co.uk/node/8 might or might not apply here. Maybe getting rid of services located in /usr/share/autostart by adding an override to /etc/xdg/autostart would be a clean solution. But is there a mechanism to overrule files located in /usr/share/kde4/services/?
The only choices to overrule the settings in /usr/share/kde4/services/ are either to delete hem directly (not good if you want to enable them again and also a package update will undo it), copy them to a ~/.kde/share/autostart under a user account and change them (changes will be persistent, reversible but we want to avoid user based changes), Not mentioned but we can go for the first option and instead of deleting the .desktop file it will instead be patched by a startup script that adds the hidden option. That way the changes survive updates, could be turned off by disabling the patching and are system wide without getting into user specific settings problems.
The correct way to disable a package installed is actually to copy it to your personal autostart folder. Anything of the same name in ~/.kde/share/autostart overrides the .desktop file in the default installations. Once we have copied the .desktop file we can make changes.
or
I’m thinking a a systemd service that automatically deletes the applet desktop file under the services folder and could be stopped if a user wishes to see the applet.
I say likely this is the .desktop file because there are bunch of them that come under a search of this folder.
The only choices to overrule the settings in /usr/share/kde4/services/ are either to delete hem directly (not good if you want to enable them again and also a package update will undo it), copy them to a ~/.kde/share/autostart under a user account and change them (changes will be persistent, reversible but we want to avoid user based changes),http://blog.davidedmundson.co.uk/node/8 doesn't mention[font=courier] /usr/share/kde4/services/[/font]. Who claims the services folder can be overruled? I haven't found any references. Unless you successfully test this, it's more likely there is no overruling mechanism for[font=courier] /usr/share/kde4/services/[/font].
And hypothetically, if [font=courier]/usr/share/kde4/services/[/font] was overruleable by [font=courier]~/.kde/share/autostart[/font], it would likely be overruleable by [font=courier]/etc/xdg/autostart[/font] and [font=courier]/usr/share/autostart[/font]. In that case, why do problematic writes to user home and not rather use any of the two latter?
Not mentioned but we can go for the first option and instead of deleting the .desktop file it will instead be patched by a startup script that adds the hidden option. That way the changes survive updates, could be turned off by disabling the patching and are system wide without getting into user specific settings problems.Inventing a patching system is hard. That effort would be better spend on the real solution.
I'm thinking a a systemd service that automatically deletes the applet desktop file under the services folder and could be stopped if a user wishes to see the applet.The problem with these approaches is that they are surprising, non-standard, hacky, creating confusion, requiring documentation and looking dilettante when you explain them "we haven't figured out how kde [url=https://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#Remove_a_widget_from_systemtray]plasma shell scripting[/url] works, so we invented this custom patching system, that you can disable by...".
We haven’t contacted the author of the solution that worked for wheezy.
Maybe that way can be fixed for jessie. Maybe just the string “org.kde.networkmanagement” changed to something else and this would be fixed.
[quote=“Patrick, post:30, topic:507”]We haven’t contacted the author of the solution that worked for wheezy.
Asked the author and also posted this on the KDE user mailing list. CC’d whonix-devel.
How to remove a widget from systemtray? removeSystrayApplet.js example is broken.Somehow the message does not get posted on the KDE user mailing list. Maybe it needs some time. Maybe some spam protection was hit due to too many recipients.
We haven't contacted the author of the solution that worked for wheezy. https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/changes/plasma/javascript/plasma-shell-scripting/removeSystrayApplet.js
Yes this seems the right and only way to do it. All tests I did with moving around and editing .desktop files to overrule default settings have not succeeded.
[quote=“Patrick, post:31, topic:507”][quote author=Patrick link=topic=532.msg8544#msg8544 date=1434552211]
We haven’t contacted the author of the solution that worked for wheezy.
[/quote]
Asked the author and also posted this on the KDE user mailing list. CC’d whonix-devel.
Somehow the message does not get posted on the KDE user mailing list. Maybe it needs some time. Maybe some spam protection was hit due to too many recipients.[/quote]
Resent without CC. Non-ideal, but at least now it reached the KDE user mailing list.
https://marc.info/?l=kde&m=143456666613517&w=2
[quote=“Patrick, post:33, topic:507”][quote author=Patrick link=topic=532.msg8546#msg8546 date=1434556828]
Asked the author and also posted this on the KDE user mailing list. CC’d whonix-devel.
Somehow the message does not get posted on the KDE user mailing list. Maybe it needs some time. Maybe some spam protection was hit due to too many recipients.
[/quote]
Resent without CC. Non-ideal, but at least now it reached the KDE user mailing list.
https://marc.info/?l=kde&m=143456666613517&w=2[/quote]
Unfortunately, no answers.
Due to the recent two support threads where this caused confusion… We should add this to known issues so it can be easily refereed to it.
Could you donate a screenshot of systray icon please?
Please reupload to the wiki because hosted images expire
Thanks. Now documented:
https://www.whonix.org/wiki/Template:Known_bugs#Network_Manager_Systray_Unmanaged_Devices
In ⚓ T296 disable kde power management in VMs HulaHoop was wondering, if the solution to disable the battery monitor systray could be replicated to disable the network manager systray. Will answer soon.
No, probably not. Because that patch breaks the systray rather than just not starting it or hiding it by default. Undoing that patch would be non-intuitive. Would require deletion of a file or some settings mechanism. (Because of the way kde handles config files after first boot: '[kde] kde settings files / packages - debugging and changing user settings as a distribution' - MARC)
It’s sane to break the battery monitor systray / power configuration in a VM so it does not show up, but breaking the network manager systray would defeat the purpose of having it installed by default in the first place. The full kde network manager menu unfortunately does not make everything available that the kde network manager systray does. Having just the full kde network manager menu available and requiring some manual action to unbreak the kde network manager systray seems like a broken solution.