Where kde saves user settings ?

[Duncan]

John_82 posted on Sat, 18 Mar 2017 16:15:50 +0000 as excerpted:

> On Sat, 18 Mar 2017 07:15:35 +0000 (UTC)
> Duncan <1i5t5.duncan at cox.net> wrote:
> 
>> John_82 posted on Fri, 17 Mar 2017 13:44:58 +0000 as excerpted:
>> 
>> > Can anyone tell me where kde stores things like
>> > 
>> > Start button menu content.
>> > Task bar content.
>> > The state a user left when they logged out so that windows will
>> > mostly be restored etc.
>> > 
>> That's actually a broader question than you likely realize, with an
>> even broader answer as the locations have changed over the years and
>> kde versions, and frameworks-5-based apps now use the standard
>> freedesktop.org specified locations, while kde4-based apps (of which
>> there are still some around that haven't migrated yet and that might be
>> dropped in a year or two when kdelibs4 goes EOL if they still haven't
>> migrated) use the old kde location.

>> For plasma5 and frameworks5 based apps, as I said, the freedesktop.org
>> speced locations are normally used.  That's $XDG_CONFIG_HOME for
>> config, and $XDG_DATA_HOME for app data.  If those aren't set... well,
>> let me point you to the freedesktop.org website for the specs and you
>> can read it yourself, but try ~/.config and ~/.local/share .
>> 
>> https://www.freedesktop.org/wiki/Specifications/
>> 
>> That has lots of different specs listed, many of which may be
>> interesting reading (they certainly do here)

> I think I have managed to sort out what is going on since asking. I was
> particulary interested in start button menu's and taskbars.

I had answered more the general kde settings angle in the last post, and 
basically ignored the specific function bit.  This one will try to 
address that a bit.

> I can summarise the start button. Desktops have menu catagory trees
> whose contents may be set by a distro. The one on opensuse contains and
> amazing number of categories eg all will have utilities. It has history,
> science and miriads of others. Along side that there is a directory with
> dot dektop files which also contain category information. These seem to
> be scaned and and linked somehow into the eventual menu.

For modern full-feature desktops (including plasma and I believe lxde as 
well, but I'm not sure if the *box and similar closer to wm-only style 
desktops have updated) at least, these are all standardized.

Take a look at the general freedesktop.org specs link from earlier.  In 
particular, you'll want to look at the *.desktop file stuff as well as 
the menu stuff.  Basically, the *.desktop files are the basic building 
blocks for the menu, but there's a utility that grabs the information 
from these and assembles (IIRC) *.menu files from them.

And yes, there's both user and system locations.  The user locations will 
be under the $XDG_*_HOME dirs (IIRC CONFIG but could be wrong), the 
system locations under the parallel system $XDG_ dirs.

The categories are pretty standardized as well.  I think the general idea 
is that if you have only a few apps in a higher category, they'll be 
listed directly under it in ordered to avoid lower level categories with 
only an item or two, while if you're really interested in say science or 
games and have a whole lot of them, the top-level category will be broken 
down further into lower level ones.  Additionally, there's often a "more" 
entry, for the (theoretically) less used apps if the number of entries in 
a category gets too high and it hasn't been broken down further.  This is 
all based on usability studies showing that having more than 5-7 choices 
at once gets confusing for many users.

> There does seem
> to be user local taskbar set ups but also something system wide and as
> you mention some apps look after specific user settings in various ways.
> A few and the desktops seem to be doing that of ~/.configure. Seems like
> a good way forwards to me.

AFAIK, taskbar stuff hasn't been standardized, so it's each desktop for 
itself.

=== Meandering a bit... thru the === below...

FWIW, I don't actually use a "taskbar" in the normal sense (the widget 
under plasma), preferring alternatives such as alt-tab, the window list 
with a desktop middle-click, multiple desktops and desktop switching 
using scroll on the desktop or the cube or grid, etc.

And I have a /huge/ desktop, a 65-inch 4K monitor for my usual work along 
with a 48-inch full-hd monitor that's often running full-screen youtube 
or the like.  I've used kwin window rules to standardize most of my main 
windows to 1280x1080, letting me do three windows wide and two high, six 
work-windows displayed at once on the 65" 4k (along with the full-screen 
video window on the 48" full-hd), so I can get quite a lot on-screen at 
the same time without needing a switcher other than focus-follows-mouse 
and alt-tab, as well, meaning that along with multiple desktops, I only 
rarely need to actually stack windows on top of each other, so I don't 
normally need a switcher for that.

So I really don't /need/ an actual taskbar, and don't have one 
configured.  I /do/ have a small panel set to autohide, mostly for the 
systray/notifier plasmoid, tho I have one each kickoff, folder/directory, 
and comic-strip plasmoids, on it as well.  I seldom use the kickoff menu, 
however, as I've setup (non-kde as kde kept breaking it every few years 
with their major version bumps) hotkey based launching for all my normal 
apps.  And if it's not there but I remember the name, I'll usually type 
it into the runner dialog.  So pretty much the only time I actually use 
kickoff is when I'm bored and searching for a new game to try or 
something, and that's quite rare.

But I do regularly use the systray, as I have my mail (claws-mail), feeds 
(separate claws-mail instance, with its feeds plugin), and news (pan, 
what I use for following mailing lists like this one, via gmane.org) apps 
among others start at plasma startup and run in the tray; I use the comic 
strip plasmoid, and I occasionally use the directory-view plasmoid to 
access a new download or something.

=== end the meandering...

So I don't actually need or use a taskbar, as such, tho I do use a small 
panel, which some people call a taskbar, in the more generic sense.  
Thus, I don't know much about the taskbar, but if you're talking about 
the panel in the more generic sense, those settings, along with the 
desktop activity settings, are mostly found in the (config location file):

plasma-org.kde.plasma.desktop-appletsrc

As that file contains the settings for most of the plasmoids as well, it 
probably contains the taskbar settings too, unless the taskbar has split 
them out into another file or files.

> I started wondering what was going on when I installed lxde as a test to
> another user account. I expectd that to give some isolation. It didn't
> my kde menu was twice the size and full of lxde apps some of which can't
> even work on a kde desktop.

That would be the fault of either lxde or the distro.  The XDG *.desktop 
specs (and thru that to the menu) have a specific line available for show-
only-in, and apps that work only in lxde should have that set to lxde.  
Similarly of course for kde/plasma.

Tho if an app actually works in other desktops, it arguably should NOT be 
restricted to show only in a specific desktop's menu, because people 
might want to run it under another desktop as well.

FWIW I believe plasma uses this mechanism to label the kde settings app 
generically as "system settings" under kde, but as "kde system 
settings" (or these days maybe it's plasma system settings... I don't 
know as the only X desktop I run is plasma/kde) under other desktops.  I 
don't actually agree with that at all, as I believe it should be "kde 
system settings" under kde as well, because that's what /most/ of the 
settings actually are.  Tho there are some generic system settings, it's 
still the kde tool for setting them, so kde system settings works just 
fine for them, too.

But to some extent in kde4, and with frameworks5 it's now the general 
rule, non-plasma-specific kde apps are specifically and deliberately 
targeted at more generic use, *NOT* specifically under kde/plasma.  As 
such, those general apps /will/ be shown by default in lxde, etc.

This goes along with the general trend to more modularity in both qt and 
kde, with apps being able to choose specific modules for their 
functionality, without having to pull in the huge monolithic dependency 
blocks that kdelibs4 and qt3 and to a lessor extent qt4 were.  Thus the 
lines between a kde app and a qt app, or a qt app and a non-qt app, are 
blurred, and many apps that used to be kde-only are now either qt apps, 
or general apps that pull in a couple of qt and/or kde modules, without 
pulling in the rest.

And in some cases, I believe marble being one of them (I've seen it in 
the marble commit logs), these apps are built and marketed as for example 
android apps, qt apps, and kde apps, all three (and possibly as a windows 
app as well, I'm not sure on that one for marble), depending on the 
platform the user is running at the time.

> I then looked at another kde user ;-) Root.
> Same there so there is no isolation even if all users use the same
> desktop.

Actually, there is isolation, but it's not as you expect.

Distros normally don't mess with user-specific config, and only install 
to the system location.  Apps installed there will of course appear in 
the apps menu for all users, with what desktops they actually show up in 
being controlled by the shown-in line as described above.

But users can control their own config, editing their menus as they 
wish.  In plasma, this is done with kmenuedit.  As it's run with user 
permissions, it /can't/ write to the system location, only the user 
location, so that's where its edits to the default system menu go.

Of course as a sysadmin, if you don't like the way the distro and 
upstreams are setting up the default system menus, the mechanism is there 
via other system locations and appropriate inheritance to add or apply 
wipeout files to remove the distro-installed entries.  The general 
mechanism for this is described in the XDG specs, tho that's at a spec 
not howto level, and I expect the kde sysadmin docs will do a bit better 
at the howto level if they actually cover it (I'm not sure of the 
coverage on this specific point).

Note that via the kde kiosk mechanism, it's also possible to lock down 
nearly all user settings as well, enforcing system settings so the user 
can't apply their own changes.  The general kiosk mechanism is there and 
because kde/plasma is used in quite a number of business and government 
environments where individual settings must be locked down to some degree 
or another, it's generally well tested and used, but if you have reason 
to use it, do keep in mind that because plasma itself is under continuing 
development and thus a moving target, so will be these kiosk lockdown 
settings.  As such, while they should keep the normal user from screwing 
things up too much, like padlocks, they work best with basically honest 
people who might need a reminder here or there, not the technically 
literate hacker type (hacker in the neutral sense here), who is 
determined to override otherwise enforced system settings (arguably black-
hat, no longer neutral).

> Something windows has coped with for a very long time.

And so does Linux/X/Unix.  In fact, the mechanisms for doing so are 
fairly highly developed.

But you're comparing individual user-scope installs on MS, to global 
system level installs on Linux.  /Naturally/ the global system level 
install is going to affect all system level users. =:^)

Now try installing apps only as a specific user, in the user's locations 
with the user's privs only (~/bin for executables, ~/lib or ~/lib64 for 
libs, etc), and see if those installs and settings get applied system-
wide.

=:^)

FWIW, this is what various projects are working on better non-tech-
literate-user automation and packaging for, now.  I believe ubuntu's 
snaps are designed to be statically linked and install only one or a few 
files, optionally to a user's home dir instead of system-wide.  There's a 
less distro-specific xdg-sponsored initiative, I forgot the name ATM, 
doing much the same thing, and kde is working on the same sort of 
mechanism, I believe using the xdg stuff as one possible module of 
several available, for the kde store, etc.

Of course the down side to all this is security, and arguably user 
freedom as well.  Most of these projects are designed to enable static 
linking, undoing the work of decades in unbundling libs, etc, so distros 
can update a single lib and by doing so secure everything in the system 
that uses it.  Forget that if every user has perhaps 50 copies of perhaps 
a dozen versions of the library statically linked into 50 different apps 
that the admin or distro trying to secure it all may have no idea were 
installed in the first place!

And most of these projects encourage binary installation, with source-
code availability optional, as well.  Great for the gamer more concerned 
about being able to run his drm-ed-up-the-yin-yang game than about 
software freedom, not so good for anyone actually concerned about that 
software freedom, or anyone trying to patch some functionality that's 
broken, themselves (the way free software got its start, when Richard 
Stallman was trying to fix a print driver he couldn't get the sources to).

> Different desktops is one of linux's advantages but not much of one if
> it works as it does. It's a mess and one kde users menu settings
> changing anothers isn't exactly good either.

As explained above, that doesn't happen, and indeed, /couldn't/ happen, 
without access to that other user's files.

You're misunderstanding global system installations in global system 
locations as individual user installations.  There's a big difference!

> So sorry about the long post.

As should be amply demonstrated by now, I'm not a short-post person 
myself.

FWIW, I've concluded there's two types of posters, those who post the one-
time problem or solution and ONLY that, short and simple but with an 
extremely poor chance of applying the next time, and those that provide 
enough detail and context that there's a good chance of the info in the 
post applying to a bunch of other related problems and solutions, thus 
ideally allowing readers to understand and fix the problems themselves 
the next time.

It should be quite obvious which one I tend to be, obviously *NOT* the 
short-poster! =:^)

> SDDM may have a problem as well. It looks like it could log into a
> desktop using the wrong menu tree. That aspect seems to be ok though as
> the lxde one contained a lot of kde apps.

You'll need to look elsewhere for help with SSDM.  I don't use a *DM at 
all, preferring to login at the text console and run a wrapper script 
from the CLI, that sets my preferred xsession (kde/plasma) and various 
other environment stuff, then runs startx.  I've not used a *DM in close 
to a decade and a half, now.  So no *DM installed at all here, and but 
for the various discussions such as this and the commit messages and bugs 
I've seen in the plasma-devel list, which I suppose do keep me somewhat 
current in general, my own *DM experience is a decade and a half old now, 
so unlikely to be particularly helpful. =:^\

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman