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@xxxxxxx> 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
