On Wednesday August 30 2017 05:20:53 Duncan wrote:
Echoing this to the plasma-devel list so that at least they're aware of the use-case (with apologies for top-replying to those who take offense).
If indeed each launcher is a separate plasmoid and each plasmoid has its own settings one could expect those to be saved in an application (pardon, plasmoid) specific rc file. If that is not the case that probably means that plasmoids don't run as individual processes but as are instead run (as scripts) by a host application (the plasma shell), and settings are stored in that host application's settings file.
I don't think it'd be very difficult to store individual plasmoid settings in such a way that they don't overwrite each other, given how the config file APIs are designed. In this particular case though it may well be that the launcher/kicker settings are stored for/under the plasmoid category instead of name so that you can change launchers and find most of your settings in the new one.
Even so that would evidently also apply to the icon setting, so my guess is that this is not being stored as a plasmoid property, but as a setting for how (where, etc) individual plasmoids are displayed. That still doesn't mean that the icon *has* to be reset (the other properties like launcher location don't, right?) but it seems a bit less surprising that it would be the case.
In short, I don't think it'd be a huge change to implement a sticky custom icon feature, but do think like Duncan that it will probably not be considered worth the effort (besides, do as the VDG tells you and use Breeze already ;) )
Duncan proposed the approach I also thought of, but that may not be feasible because of how settings files are used (typically rewritten as soon as you change something, and rarely if ever monitored for external changes). Apparently you (Franklin) change your launcher often enough for the icon issue to become one, so maybe there's yet another workaround. Myself I use Lancelot on my Plasma4 desktop, but sometimes need the standard kicker to save an updated session configuration. If that happens I just add the standard kicker to my secondary panel, and do what I want to do. If I needed this frequently I'd leave the kicker there.
You could try the same thing: add 1 or 2 additional launchers and set them to kickoff and/or kickerdash. With luck the plasma shell will remember all settings you configure for each of those launchers - if it doesn't you could probably report that as a bug that ought to be considered more seriously than your original issue.
R.
>Franklin Weng posted on Tue, 29 Aug 2017 20:26:39 +0800 as excerpted:
>
>> In Plasma 5 we can right-click on the start menu and set our own icon.
>> However when I switch my menu from kicker to kickoff or kickerdash, the
>> menu icon changed to the default one and when I switch back to the
>> kicker, my own icon was gone and the default one is used. Would anyone
>> please tell me how to keep my own icon in the kicker mode, or even when
>> switching to different menu mode?
>
>Good question.
>
>Unfortunately, as implemented it's not possible (except for source
>patching[1]), and I'm not sure the plasma devs would consider it worth
>the very likely rather large effort to make it possible.
>
>The problem is that each of the different types of "application launcher"
>is its own separate "plasmoid", that is, component-widget, complete with
>its own settings.
>
>For most plasmoids, switching from one to another is a process of
>deleting the one, selecting add widget, and in the resulting plasmoid/
>widget-explorer dialog, dragging the one you want to replace the one you
>just deleted to the appropriate location. Then, depending on the
>plasmoid, you may have to configure the new one to do what you want.
>
>Now it so happens that with the "launcher" plasmoids, they've created a
>shortcut to all that, that lets you replace the one launcher with another
>one without going thru the whole delete/add process manually. But the
>different types of launcher are still entirely different plasmoids, each
>with their own settings and defaults, and replacing one with another
>deletes the configuration for the replaced one and sets the configuration
>of the new one to all defaults.
>
>So as I said, you can patch the sources to change those defaults and then
>you'll get your patch-altered defaults every time you switch, but other
>than that, there's no real way to do it.
>
>Wait... I actually just thought of another way, that I use sometimes
>myself.
>
>You can backup the config file before you make your change. Then make
>your change, configure the new one as you like, and do a second backup,
>keeping copies of both. Then when you need to switch, you can simply
>kill plasmashell so it doesn't overwrite your changes, restore the
>appropriate backup with your desired settings, and restart plasmashell so
>it sees the altered component, along with the settings you had previously
>configured for it.
>
>The file with all the activity/desktop, panel, and plasmoid settings, is
>
>$XDG_CONFIG_HOME/plasma-org.kde.plasma.desktop-appletsrc [2]
>
>This file, like most kde/plasma config files, is organized much like the
>standard INI file from the MS-Windows-3 era. Unfortunately, while
>there's a section hierarchy, the sections are numbered rather than named,
>so you have to read the settings and deduce what container or plasmoid
>each number represents, making hand editing possible but rather more
>difficult than it might be.
>
>Which is why I suggested using the plasma GUI to configure things and
>simply backing up the file when it has a set of settings you want to
>save, so you can switch between multiple configurations by simply killing
>plasmashell, switching the config file, and restarting it.
>
>---
>[1] Not possible except for source patching: It's always possible to
>modify the sources to set your own default. Plasma is of course
>freedomware with the sources available in ordered to /encourage/
>patching, and while I don't claim to be a dev, I do run gentoo so already
>build from sources, and if I'm motivated enough I sometimes surprise
>myself at what sort of patches I can hack up! Were I motivated enough,
>I'm sure this one would not be an issue, since at least in theory it's
>simply replacing one image with another, so the biggest issue would be
>actually looking at the code long enough to find the image to replace,
>and that shouldn't be difficult at all, only requiring time, which is why
>I have to be motivated enough to prioritize finding the location /to/
>patch and creating and testing the patch above whatever else I'd
>otherwise be doing with that time.
>
>[2] $XDG_CONFIG_HOME: If this variable isn't set, the default is
>~/.config, ~ of course being your user's home dir. So the complete
>default path would be: ~/.config/plasma-org.kde.plasma.desktop-appletsrc
>
>
