On Sun, 19 Mar 2017 00:35:26 +0000 (UTC)
Duncan <1i5t5.duncan@xxxxxxx> wrote:
> 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
>
It looks very much like a distro problem to me but without knowing how the priorities of the various folders work it's hard to say. I have seen a comment for instance that if a user local menu folder is added it will over ride the system one. That makes a lot of sense to me especially if others can do the same. Some probably extend.
I suspect the desktop type tags in dot desktop files have been dropped as people often run a mix. I do for instance. I wanted to know what my cpu was up to. I could type something in the console but I'd rather have a desktop utility. Xfce seemed to be the best source so installed it. Some how that pulled in their console. So I get that in my menu too. I've not tried removing any yet and assume a don't show tag is added to the menu category tree. For all I know they might just delete the dot desktop file. Doubt that because on kde there is an option to hide them. Rather a lot to do if a different desktop is installed. Tedious is an understatement. My impression is that the desktop people are aiming at similar functionality pc wide as windows has. Once that is done distro's need to add install user local or pc wide. ;-) I'll try not to say system wide again. I'm not a pc software person but think that doesn't really need much work. On opensuse I mostly install supported binaries with
a single click. The dot desktop file will be the same where ever it's put so could have an option to install user local so the path needs to added when it's installed. If I compile I could move it myself. I often have to find them anyway. A pretty simple utility could selectively move dot desktop files to user local places. ;-) Wish I could write one but the vast bulk of software I have written has been in obscure languages, C and a lot more assembler but none on pc's that are window related. Just a few bits and pieces that ran on msdos. Best not say what I thought about the junk in that.
SDDM is pretty modern. ;-) No more 80's syntax to set it up. It allows a single user to run different desktops and also a system default. It selects the correct menu category tree, sets some variables such as windowmanager and allows a script to be run before logging in and another on log out. So startx, start lxde etc can be run. There doesn't seem to be a way of extending these to avoid updates removing additions. It can also cope with auto login and there may be an option to make that a one off. That can be done on a per user basis so may allow the desktop for a user to always be the same unless they set another. Otherwise it remembers the last desktop used irrespective of who used it. So when I fired up lxde and went back to my usual kde one it loaded it as lxde. Net effect - desktop folders needed 2 clicks to open and then one to navigate. Lxde had both a wastebin and a wastebasket. Suspect one is from xcfe. Maybe kde not sure. Seems things like sddm should be called greeters no
w. One side effect of it on opensuse seems to be that it's now not possible to log into a shell. Might be a problem elsewhere but suspect not. I'm told that if someone logs into a shell assuming kde will be used that it sees it's not installed and promptly adds a number of folders.
It's been sort of fun. All I wanted to do was to create some truly isolated desktops to play with for fun. Compiz etc. The only way I can find out what is going on is via system wide content searches They take ages. Some one at one point thought yes it would be a good idea to be able to exclude directories from searches in dolphin but it never happened. Kfind could do that but doesn't unless the locate index is used. ;-) I'm moaning.
A number of people think that the only way to get a true feel for another desktop is to use a vm. It shouldn't be needed and then I find any desktop is a bit of a mess in this respect all it seems down to the distro's. I have seen kde provide different menu's for different users in the past but only if I used the desktop as root. I assume they still aim for things to work like that for all. The first time I logged in a root all it had was a console. I complained on here. A later release had some sensible bits and pieces in it. Now it's exactly the same as my normal desktop.
;-) I'd had enough of various styles of console editors years ago so wont use them unless they are the only way to do something. Many things can be done from the desktop anyway. Dangers are all down to the user. All I need do if I mess up a system file is just replace it with the backup or create several and try each one. Only a few shell commands are needed to do that. I don't use it often enough to remember many.
John
-
