From kde Wed Aug 30 12:59:50 2017 From: Eike Hein Date: Wed, 30 Aug 2017 12:59:50 +0000 To: kde Subject: Re: start menu icon Message-Id: <782252FD-26E1-4C30-887B-9257AED5F2C9 () kde ! org> X-MARC-Message: https://marc.info/?l=kde&m=150411454810866 On August 30, 2017 6:59:30 PM GMT+09:00, Franklin Weng wrote: >Hi, > >Thanks for Ren=C3=A9 and Duncan's reply=2E > >Honestly it's not because *I change the menu so frequently*=2E It's >something what I've presented in the Akademy 2017 about Plasma 5 >customization, without changing any existing file=2E We used our own >start menu icon and I set it in the desktop scripts which uses kicker >launcher=2E But when I change the launcher the settings was gone (and >back to the KDE default)=2E > >I know that kicker, kickoff and kickerdash are different plasmoids and >the icons are set in their =2Edesktop files=2E 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=2E 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=2E > >Thanks for the developers for your work, and I wish it can be >considered >to implement=2E > > >Franklin > > >Ren=C3=A9 J=2EV=2E Bertin =E6=96=BC 2017=E5=B9=B408=E6=9C=8830=E6=97=A5 1= 6:18 =E5=AF=AB=E9=81=93: >> 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)=2E >> >> 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=2E 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=2E >> >> 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=2E 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=2E >> >> 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=2E 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=2E >> >> 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)=2E Apparently you (Franklin) change your launcher often enough >for the icon issue to become one, so maybe there's yet another >workaround=2E Myself I use Lancelot on my Plasma4 desktop, but sometimes >need the standard kicker to save an updated session configuration=2E If >that happens I just add the standard kicker to my secondary panel, and >do what I want to do=2E If I needed this frequently I'd leave the kicker >there=2E >> You could try the same thing: add 1 or 2 additional launchers and set >them to kickoff and/or kickerdash=2E 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=2E >> >> R=2E >> >> >>> 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=2E >>>> 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=2E 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=2E >>> >>> Unfortunately, as implemented it's not possible (except for source=20 >>> patching[1]), and I'm not sure the plasma devs would consider it >worth=20 >>> the very likely rather large effort to make it possible=2E >>> >>> The problem is that each of the different types of "application >launcher"=20 >>> is its own separate "plasmoid", that is, component-widget, complete >with=20 >>> its own settings=2E >>> >>> For most plasmoids, switching from one to another is a process of=20 >>> deleting the one, selecting add widget, and in the resulting >plasmoid/ >>> widget-explorer dialog, dragging the one you want to replace the one >you=20 >>> just deleted to the appropriate location=2E Then, depending on the=20 >>> plasmoid, you may have to configure the new one to do what you want=2E >>> >>> Now it so happens that with the "launcher" plasmoids, they've >created a=20 >>> shortcut to all that, that lets you replace the one launcher with >another=20 >>> one without going thru the whole delete/add process manually=2E But >the=20 >>> different types of launcher are still entirely different plasmoids, >each=20 >>> with their own settings and defaults, and replacing one with another > >>> deletes the configuration for the replaced one and sets the >configuration=20 >>> of the new one to all defaults=2E >>> >>> So as I said, you can patch the sources to change those defaults and >then=20 >>> you'll get your patch-altered defaults every time you switch, but >other=20 >>> than that, there's no real way to do it=2E >>> >>> Wait=2E=2E=2E I actually just thought of another way, that I use somet= imes > >>> myself=2E >>> >>> You can backup the config file before you make your change=2E Then >make=20 >>> your change, configure the new one as you like, and do a second >backup,=20 >>> keeping copies of both=2E Then when you need to switch, you can >simply=20 >>> kill plasmashell so it doesn't overwrite your changes, restore the=20 >>> appropriate backup with your desired settings, and restart >plasmashell so=20 >>> it sees the altered component, along with the settings you had >previously=20 >>> configured for it=2E >>> >>> The file with all the activity/desktop, panel, and plasmoid >settings, is >>> >>> $XDG_CONFIG_HOME/plasma-org=2Ekde=2Eplasma=2Edesktop-appletsrc [2] >>> >>> This file, like most kde/plasma config files, is organized much like >the=20 >>> standard INI file from the MS-Windows-3 era=2E Unfortunately, while= =20 >>> there's a section hierarchy, the sections are numbered rather than >named,=20 >>> so you have to read the settings and deduce what container or >plasmoid=20 >>> each number represents, making hand editing possible but rather more > >>> difficult than it might be=2E >>> >>> Which is why I suggested using the plasma GUI to configure things >and=20 >>> 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=20 >>> plasmashell, switching the config file, and restarting it=2E >>> >>> --- >>> [1] Not possible except for source patching: It's always possible >to=20 >>> modify the sources to set your own default=2E Plasma is of course=20 >>> freedomware with the sources available in ordered to /encourage/=20 >>> patching, and while I don't claim to be a dev, I do run gentoo so >already=20 >>> 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,=20 >>> I'm sure this one would not be an issue, since at least in theory >it's=20 >>> simply replacing one image with another, so the biggest issue would >be=20 >>> actually looking at the code long enough to find the image to >replace,=20 >>> and that shouldn't be difficult at all, only requiring time, which >is why=20 >>> I have to be motivated enough to prioritize finding the location >/to/=20 >>> patch and creating and testing the patch above whatever else I'd=20 >>> otherwise be doing with that time=2E >>> >>> [2] $XDG_CONFIG_HOME: If this variable isn't set, the default is=20 >>> ~/=2Econfig, ~ of course being your user's home dir=2E So the complet= e=20 >>> default path would be: >~/=2Econfig/plasma-org=2Ekde=2Eplasma=2Edesktop-appletsrc >>> >>> This is already implemented and the correct way is to ship an applet confi= g initialization script in your look and feel package=2E The config will th= en be initialized with your values every time the applet is created=2E Vari= ous distros use them for e=2Eg=2E the launcher default icon=2E Netunner is = an example=2E Marco, we have docs for this somewhere right? :) Cheers, Eike --=20 Plasma, apps developer KDE e=2EV=2E vice president, treasurer Seoul, South Korea