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.dun...@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
