[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde
Subject:    Re: start menu icon
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2017-08-30 8:18:09
Message-ID: 13554045.2bF3ajn8Dn () bola
[Download RAW message or body]

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
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]