[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Fix Unmanaged Devices Network Manager

I haven’t forgotten about this, as soon as I have time I will create a KDE account and help out with the topics you need to ask about.

[quote=“Patrick, post:11, topic:507”][quote author=Patrick link=topic=532.msg4146#msg4146 date=1411287818]

  • kde discuss debuggbility of distro settings
  • kde discuss changing user settings through upgrade by distro
    [/quote]
    kde settings files / packages - debugging and changing user settings as a distribution
    http://lists.kde.org/?l=kde&m=141130406809446&w=2[/quote]
    Unfortunately, no answers.

[quote=“Patrick, post:10, topic:507”]- kde hide icons in taskbar by default, example of scripted desktop

Now we gotta find how how to apply it.

Here is what I think needs to be done with this script:

They can also be put in share/plasma-desktop/init/ to set up Plasma layouts on first log-in (or whenever there is no existing configuration) or in share/plasma-desktop/updates/ to alter the plasma-desktop configuration on its next start.

The /updates/ folder also solves the “changing user settings through upgrade by distro rather then fresh build” question.

Committed a fix. I am not entirely sure it works due to difficulties debugging this stuff as explained above. A new image build will show. Chances are good.

It’s back since jessie / Whonix 11. But in another form.

Do we to leave it as is or try to remove it?

Removal is better because they don’t show useful information anyway. Should I research how?

Yes, please.

https://forum.kde.org/viewtopic.php?f=66&t=106780#p245567

~/.kde/share/config/plasma-desktop-appletsrc

[Containments][1][Applets][6][Configuration][Applets][9] geometry=0,0,24,24 immutability=1 plugin=org.kde.networkmanagement zvalue=0

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:
https://www.whonix.org/forum/index.php/topic,532.msg5067.html#msg5067

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:
https://askubuntu.com/questions/171119/how-to-control-kde-4-9-0-plasma-widgets-from-command-line[/quote]
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:

Which 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.
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/changes/plasma/javascript/plasma-shell-scripting/removeSystrayApplet.js

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.
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/changes/plasma/javascript/plasma-shell-scripting/removeSystrayApplet.js[/quote]
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.
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]