start menu icon

[Marco Martin]

where was this? on entrprise list?
(btw for that i would suggest a "branded" icon theme that fals back to breeze 
and just replaces the icons that should have the distro brand on it)

On mercoledì 30 agosto 2017 10:18:09 CEST René J.V. Bertin wrote:
> 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


-- 
Marco Martin