Web lists-archives.com

Re: start menu icon




On August 30, 2017 6:59:30 PM GMT+09:00, Franklin Weng <franklin@xxxxxxxxxxxxxxxx> 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