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

List:       kde
Subject:    Re: start menu icon
From:       Eike Hein <hein () kde ! org>
Date:       2017-08-30 12:59:50
Message-ID: 782252FD-26E1-4C30-887B-9257AED5F2C9 () kde ! org
[Download RAW message or body]

On August 30, 2017 6:59:30 PM GMT+09:00, Franklin Weng <franklin@goodhorse.idv.tw> \
wrote:
> 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
> > > 
> > > 

This is already implemented and the correct way is to ship an applet config \
initialization script in your look and feel package. The config will then be \
initialized with your values every time the applet is created. Various distros use \
them for e.g. the launcher default icon. Netunner is an example.

Marco, we have docs for this somewhere right? :)

Cheers,
Eike
-- 
Plasma, apps developer
KDE e.V. vice president, treasurer
Seoul, South Korea


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