Favorites are stored in an sqlite database shared by launcher frontends, not in the applet configuration. This doesn't work because the configuration is only used to seed that database during an initial migration with an empty database.

My guess is that you're trying to modify the session setup script, which runs too late. The correct way to do this is via the per-applet plasmoidsetupscripts/* scripts in an LnF package.

No, I'm running it through qdbus trying to verify how to actually do anything and it doesn't work.

If the correct way is in some other arbitrary undefined way (which you keep referring to), it should be CLEARLY documented because the implementation of how the configuration is handled is obviously not done in the correct way now, from a users or administrators perspective.

If it had been done correctly I wouldn't have spent 40+ hours trying to solve something which should only be ONE line in a configuration file. 

Instead I'm now trying to write some Javascript in accordance to whatever information is available (https://userbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting) and it still doesn't work, which again leads me to the conclusion that the way it is handled is absolutely the wrong way of doing it.

here is a file from a distro that sets a custom favorite list at startup.

the file name is "look and feel name"/contents/plasmoidsetupscripts/org.kde.plasma.kickoff.js

the contents of the js file are:


applet.currentConfigGroup = ["General"]

applet.writeConfig("favorites", "preferred://browser,kontact.desktop,systemsettings.desktop,org.kde.dolphin.desktop")

applet.currentConfigGroup = ["Shortcuts"]
applet.writeConfig("global", "Alt+F1")

applet.reloadConfig();

Note in kicker docs say the key is "favoriteApps" . "favorites" is for kickoff

Trying that, just adjusting the script I had in the initial report, with config groups, doesn't work either. Running it through the desktop shell scripting console, the only thing changed is ~/.config/plasma-org.kde.plasma.desktop-appletsrc which now contains a line with favoriteApps=konsole.desktop,firefox.desktop

I did an strace on it too (plasmashell PID as it seems to run in that context) and couldn't find anything changing but that file either, so the conclusion is that the only thing changed by using that JavaScript is that specific file.

So, adding favoriteApps to the default plasma-org.kde.plasma.desktop-appletsrc file that a user gets should accoring to that get the favorites specified? But that doesn't happen either which still leaves me with the patch as the only working solution.

Or you could use the supported solution that distros use and is known to work as described by Marco ...?

Isn't the underlying issue that it only looks at the favorite apps once, then sets the "MigratedToKAStats" flag and never looks at the config file again?
So yeah for initial setup Marco's solution is the way to go, for changing the favorites after that, I don't know.

(In reply to Eike Hein from comment #6)
> Or you could use the supported solution that distros use and is known to
> work as described by Marco ...?

Which doesn't really seem to be described or documented how it works and how to do it anywhere.. The fact that you need to be a developer of the package to do any configuration of it is in itself a serious flaw.

Not to mention that what I'm guessing on how its supposed to look like doesn't work either (pretty much the same script but named it org.kde.plasma.kicker.js and have that ["General"] config group stuff in it..)

Setting the flag "favoritesPortedToKAstats=false" in the file that it's writing to doesn't seem to make the menu appear correctly either. It will update it to true when logging in though.

(In reply to Eike Hein from comment #6)
> Or you could use the supported solution that distros use and is known to
> work as described by Marco ...?

You keep repeating the same nonsense which is just annoying. If it was usable "use the supported solution" I wouldn't be here, would I?

The fact that this seems to be so extremely hard to do should really tell you something about how it's handled right now and the serious flaws with it.

I always thought the Windows Registry was a bad way of handling stuff, but compared to how THIS seems to be done, the registry is a dream, at least in that case I could use a login script to add a registry key and make the changes I want.

Linux and KDE in general always had such easy and understandable config files for handling the configuration, which really was a selling point for customization. The fact that the discussion right now is how to make a JAVASCRIPT to change favorites for a user.. It's just mind boggling..

Nothing about my statements say I like the way it's currently implemented or think it's well-documented. Personally, I can understand your frustration.

That said, you're misusing a _bug tracker_ for a user support request, and despite that & wasting everyone's time inappropriately by keeping it going we're all still taking the time to give you pointers, so I can't understand taking the frustration out on us.

Here's a sample script from the Netrunner distro, fwiw: https://github.com/netrunner-rolling/artwork-lnf-theme-netrunner-black/blob/master/usr/share/plasma/look-and-feel/org.kde.netrunner-black.desktop/contents/plasmoidsetupscripts/org.kde.plasma.kickerdash.js

And FWIW, the reason an rc file in skel isn't a good solution is because users can at any point remove the widget and add it back (and switching between widgets using "Alternatives" corresponds to a remove+add). They can also plug in a new monitor and add a new panel with a launcher, which is also a new instance.

The skel solution would set default favs initially, and then a different set of favorites would be used each subsequent time (including the new panel case). Distros usually want the same custom set of default favs in every scenario. The per-widget initialization script runs every time.

(In reply to Eike Hein from comment #10)
> Nothing about my statements say I like the way it's currently implemented or
> think it's well-documented. Personally, I can understand your frustration.
> 
> That said, you're misusing a _bug tracker_ for a user support request, and
> despite that & wasting everyone's time inappropriately by keeping it going
> we're all still taking the time to give you pointers, so I can't understand
> taking the frustration out on us.

It's not a support issue, it was actually something that didn't produce the expected result (i.e. a bug), running that code did nothing and I expected it do to what I kind of guessed what it should do. And in the previous bug, I even figured out how the code worked and added a patch to kicker so that it would honor the configuration in the config file.

Sure, the user might change panels, applets, etc, it's hard to prevent.. But the problem is that the DEFAULTS are pretty much impossible to change for someone who isn't a/the developer. THAT is a bug and a serious problem.

I'm not a distro, I'm not making a distro, I'm just trying to customize a few things for users (be it /etc/skel/ or defaults added to a network share with the home folder for the user, or wherever its stored) and since changing the files didn't work, I assumed it was a bug and reported it, even with a patch to fix it (which most bug reports don't include and you'll agree with me on that).

Even if you see it as a "user support request", try entering the first thing you wrote to me (previous bug report) in Google and see how many useful search results you find: "Plasma LnF package".

For future references and hopefully google-able result:

To change default favorites in kicker, ignore all javascript which doesn't work (the netrunner link didn't do it either, tried putting it pretty much all over the system)

/etc/.skel/config/:

Add a plasma-org.kde.plasma.desktop-appletsrc file with the panel, applet, applet configuration you want (ISO date format, 24h clock etc).

Include the configuration for kicker (applet 16 or whatever it happens to be in your case), but remove everything except (related to kicker-applet):

[Containments][2][Applets][16]
immutability=1
plugin=org.kde.plasma.kicker

[Containments][2][Applets][16][Configuration]
PreloadWeight..


Overwrite /usr/share/plasma/plasmoids/org.kde.plasma.kicker/contents/config/main.xml (via dpkg-divert or some other method, compiling a customized version of kicker maybe, but then you might as well use the patch in bug #410222 to make it get favorites from the config file) with a version with your new hardcoded favorites as it's not configurable.

The important part in that file is the "favoriteApps" <default>-string, which you will change.

Do not include the files kactivitymanagerdrc and kactivitymanagerd-statsrc files in /etc/skel/.config - if those are present it won't work.

I don't think downstream patching the config.xml file is worthwhile.