Hi, Thanks for René and Duncan's reply.
Honestly it's not because *I change the menu so frequently*. It's something what I've presented in the Akademy 2017 about Plasma 5 customization, without changing any existing file. We used our own start menu icon and I set it in the desktop scripts which uses kicker launcher. But when I change the launcher the settings was gone (and back to the KDE default). I know that kicker, kickoff and kickerdash are different plasmoids and the icons are set in their .desktop files. I ask here to see if there's any other way to achieve the goal so that I can study how to customize it in our system. Anyway, IMHO saving plasmoids (not only launchers) settings in a separate file as an override to default setting values should make sense, just like look-n-feel packages. Thanks for the developers for your work, and I wish it can be considered to implement. Franklin René J.V. Bertin 於 2017年08月30日 16:18 寫道: > 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 >> >>
signature.asc
Description: OpenPGP digital signature
