[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic