Re: Where kde saves user settings ?
On 03/19/2017 11:54 AM, John wrote:
Thanks for that Stephen. Having looked at the freedesktop spec that's
useful and I am rather lost at that level. However I am stuck with
BASH. I need help at times and it's always BASH. However I have seen
some info on changing shells on the fly and going back to the default
again. :-) That still looks pretty cryptic in places to me though.
However if needs must. I'd prefer something for all xdg* in etc.
Haven't a clue what the in would be.
John
-
John,
BASH is a superset of POSIX. pretty much anything that's POSIX shell
works in BASH. I try to use the more restrictive POSIX set for
compatibility and only use BASH extended features if it would be too
painful to use POSIX only. (e.g. process substitution is just SO
convenient)
So, just stick that snippet in a file (e.g. "xdg-vals") add "#!/bin/sh"
or even "#!/bin/bash" to the top, make it executable (chmod 700
xdg-vals) and run it with ./xdg-vals.
so, for example:
#!/bin/bash
echo "[XDG Environment]"
while read var default; do
printf "%24s = %s\n" "${var}" "$(eval echo \${$var-${default}\(\*\)})"
done<<"EOF"
XDG_DATA_HOME ${HOME}/.local/share
XDG_CONFIG_HOME ${HOME}/.config
XDG_DATA_DIRS /usr/local/share/:/usr/share/
XDG_CONFIG_DIRS /etc/xdg
XDG_CACHE_HOME ${HOME}/.cache
XDG_RUNTIME_DIR /run/user/$(id -u)
XDG_SESSION_ID
XDG_SESSION_COOKIE
XDG_SESSION_TYPE
XDG_SESSION_CLASS
XDG_SESSION_DESKTOP
XDG_CURRENT_DESKTOP
XDG_SEAT
XDG_VTNR
XDG_DESKTOP_DIR $HOME/Desktop
XDG_DOCUMENTS_DIR $HOME/Documents
XDG_DOWNLOAD_DIR$HOME/Downloads
XDG_MUSIC_DIR $HOME/Music
XDG_PICTURES_DIR$HOME/Pictures
XDG_PUBLICSHARE_DIR $HOME/Public
XDG_TEMPLATES_DIR $HOME/Templates
XDG_VIDEOS_DIR $HOME/Videos
EOF
echo "(*) indicates variable unset and a default value substituted"
--stephen
Re: Where kde saves user settings ?
On Sat, 18 Mar 2017 22:36:22 -0600
Stephen Dowdy wrote:
> > 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/
> >
>
> FYI: here's a little POSIX shell snippet i use for diagnostics that can
> show you current XDG settings:
>
> echo "[XDG Environment]"
> while read var default; do
> printf "%24s = %s\n" "${var}" "$(eval echo \${$var-${default}\(\*\)})"
> done<<"EOF"
> XDG_DATA_HOME ${HOME}/.local/share
> XDG_CONFIG_HOME ${HOME}/.config
> XDG_DATA_DIRS /usr/local/share/:/usr/share/
> XDG_CONFIG_DIRS /etc/xdg
> XDG_CACHE_HOME ${HOME}/.cache
> XDG_RUNTIME_DIR /run/user/$(id -u)
> XDG_SESSION_ID
> XDG_SESSION_COOKIE
> XDG_SESSION_TYPE
> XDG_SESSION_CLASS
> XDG_SESSION_DESKTOP
> XDG_CURRENT_DESKTOP
> XDG_SEAT
> XDG_VTNR
> XDG_DESKTOP_DIR $HOME/Desktop
> XDG_DOCUMENTS_DIR $HOME/Documents
> XDG_DOWNLOAD_DIR$HOME/Downloads
> XDG_MUSIC_DIR $HOME/Music
> XDG_PICTURES_DIR$HOME/Pictures
> XDG_PUBLICSHARE_DIR $HOME/Public
> XDG_TEMPLATES_DIR $HOME/Templates
> XDG_VIDEOS_DIR $HOME/Videos
> EOF
> echo "(*) indicates variable unset and a default value substituted"
>
Thanks for that Stephen. Having looked at the freedesktop spec that's useful
and I am rather lost at that level. However I am stuck with BASH. I need help
at times and it's always BASH. However I have seen some info on changing shells
on the fly and going back to the default again. :-) That still looks pretty
cryptic in places to me though. However if needs must. I'd prefer something for
all xdg* in etc. Haven't a clue what the in would be.
John
-
Re: Where kde saves user settings ?
On Sun, 19 Mar 2017 00:35:26 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > John_82 posted on Sat, 18 Mar 2017 16:15:50 + as excerpted: > > > On Sat, 18 Mar 2017 07:15:35 + (UTC) > > Duncan <1i5t5.dun...@cox.net> wrote: > > > >> John_82 posted on Fri, 17 Mar 2017 13:44:58 + 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
Re: Icon size in Okular and other applications
solitone posted on Sun, 19 Mar 2017 08:17:39 +0100 as excerpted: > Just a curiosity. In debian it seems I don't have any indication on > slots, so it's not immediate to know whether a package is based on > kde4 or framework5. For instance: > > solitone@alan:~$ apt-cache policy okular > okular: > Installed: 4:16.08.2-1+b1 > Candidate: 4:16.08.2-1+b1 > > solitone@alan:~$ apt-cache policy kde-baseapps-bin > kde-baseapps-bin: > Installed: 4:16.08.3-1 > Candidate: 4:16.08.3-1 > > kde-baseapps-bin is the debian package providing kdialog. > > Is there a quick and easy way to find out whether an application is > based on kde4 or framework5, apart from looking at the version details > in every application? FWIW, slots are gentoo's package-management mechanism for allowing multiple versions of something to be installed at the same time, assuming of course that they don't actually install any files to exactly the same path. Most commonly slots are used for libraries where the filenames don't collide because they're say *.so.1.2.3 and *.so.2.3.4, but they are often used for things like desktop major versions as well, to make tracking what's installed easier even when installing all packages of both slots isn't actually supported, and that's what you see here. Slots default to 0 if unset, and that's what most packages that haven't been specifically designed to allow more than one version to be installed at the same time use. So it's not surprising that Debian doesn't have an exactly similar mechanism because slots, as seen here, are gentoo-specific. **BUT**... There should be a way to query dependencies, and they have to be set correctly no matter the package management system or the package will have much bigger problems. I don't know Debian's packaging system well enough to give you an exact command, but querying it for what it depends on, and then piping that query to a grep for something like kdelibs, a kde4-only package that any kde4-based app should depend on, should work. Or grep for the qt dependency, qt4 or qt5. Alternatively, a method that doesn't depend on a package-manager query, but instead on the elf-executable information, run ldd on one of the binaries. That should produce a list of all the libraries it's linked against, and again, you can grep that for kdelibs or one of the qt libraries, and see that way whether it's kdelibs4 or kde-frameworks5 based, or qt4/5 based. You'll probably have to play around with the command and grep a bit (does the STDOUT or STDERR need piped to grep? do you want to do a grep -q and rely only on exit code, or do you prefer to see the actual grepped line, etc.), but either of these should be reliable enough to script if you like, once you get it working. Then you'll have your own script to run and won't have to remember the details. =:^) Someone here that's more familiar with Debian package management can probably post a nice one-liner, if you're not comfortable using grep, etc. -- 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
Re: KWin5 and colour scheme special application setting
On Sunday March 19 2017 08:35:46 Duncan wrote: >both the menu colors but still uses the default titlebar colors. Only >breeze seems to honor all four elements, active and inactive titlebar >colors, and foreground and background menu colors, for the window-rule >selected titlebar color scheme instead of the global color scheme. That's exactly the KWin style I'm using. QtCurve's window style isn't functional yet for KF5, sadly. What I just realise is that these window context menus use the application style. So this may in fact be an issue in QtCurve. R.
Re: KWin5 and colour scheme special application setting
Duncan posted on Fri, 17 Mar 2017 05:48:36 + as excerpted: > However, FWIW, the window rule action for titlebar colorscheme is fairly > new, and from what I can tell, still very bugged-out/broken. It's > effectively broken here. It appears to do nothing, and most of the > time, it resets to breeze no matter what I tried to reset it to. And > even tho it says breeze and that's not my default, it doesn't seem to > do anything -- it doesn't change it from the custom scheme that /is/ > my default. I just chanced to figure out what /part/ of the problem was, here! While I believe it's a bug in the window-rules settings dialog that keeps resetting it to breeze under normal conditions, and I didn't figure out any more information about /that/ bug... The reason I used the "most of the time" wording above, was that under some as yet not completely figured out conditions, perhaps including leaving the dialog /without/ actually hitting apply, the window-rule titlebar color scheme action /would/ actually stick and be the same when I returned to it, tho it didn't seem to actually make any difference. What I just chanced to figure out, because in my experiments for this thread I left the color scheme on the window rule for one of my commonly used windows set to something entirely different than my normal scheme despite it not appearing to actually work... ... is that it /was/ actually working. I just wasn't seeing it due to my selection of the plastik window decoration, which apparently doesn't have the quirk in it that allows the titlebar (itself, the actual titlebar) colorscheme to be set differently for different apps. While (unlike the oxygen decoration, which appears to use the inactive titlebar color for both active and inactive) the plastik decoration does actually change the active and inactive titlebar colors to match the global color scheme, it forces all titlebars to the same global scheme, not allowing for kwin to set individual titlebars to a different colorscheme, as the breeze decoration (for instance) does. So I wasn't seeing any changes in the titlebars themselves because of the plastik decoration. But apparently I hadn't actually opened a titlebar window menu at the appropriate time to notice that despite the titlebar itself not changing color due to the plastik decoration not supporting that, the window menu *WAS* actually changing color to match the rule. After having left the window rule color scheme setting set to something wild, eventually (just now!) I chanced to open the window menu for that titlebar, and despite the titlebar not changing color due to the plastik decoration apparently not supporting that, the window menu color *WAS* changed! So it /was/ working, I just hadn't seen it. After figuring out that the menus were showing up changed even if the titlebar itself wasn't, right away I realized it must be the window decoration I was using that prevented me from seeing the setting in the window titlebar itself. So I quickly went to the window decorations setting and tried switching to breeze. Sure enough, as soon as I did, the drastically different color scheme I had set for that window actually showed up. And... with a bit more checking, I verified that indeed, with breeze set as the window decoration, both the menu background and foreground colors were that of the specified for that window titlebar colorscheme. Same with plastik; altho it didn't actually change the titlebar color, it /did/ change both the background and foreground menu colors. And with the oxygen decoration, it changed both foreground and background menu colors, as well as changing the titlebar color (to the inactive color even when active, since that's all it uses). So what elements actually get changed do indeed appear to depend on the window decoration. You mentioned qtcurve as your widget style, but I don't see what window decoration you're using. Presumably, whatever it is only honors the menu text setting, while keeping the default menu background, just as oxygen seems to use inactive titlebar color for both active and inactive, while honoring both menu colors, and plastik honors both the menu colors but still uses the default titlebar colors. Only breeze seems to honor all four elements, active and inactive titlebar colors, and foreground and background menu colors, for the window-rule selected titlebar color scheme instead of the global color scheme. Meanwhile, now that I figured that out, I have to go try to figure out how to get that window's titlebar colorscheme setting back to default... Actually wasn't too hard as I could just uncheck the setting there, I didn't have to actually figure out what the bug is that keeps the setting from changing schemes most of the time when I'm actually trying to do that, and work around it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if y
Re: Icon size in Okular and other applications
Hi Duncan, and thanks for your clarification on versions: On Sunday, 19 March 2017 01:19:45 CET Duncan wrote: > According to my package query on gentoo: > > $equery list -op okular > * Searching for okular ... > [-P-] [ ] kde-apps/okular-16.08.3:4/16.08 > [-P-] [ ] kde-apps/okular-16.12.3:5 > [...] > 16.08.3 is slot 4 (subslot 16.08), interpreted as kde4 based. > 16.12.3 is slot 5, thus kde-frameworks5 based. > > Similar version and slot results for kdialog, so it too was still kde4 > back in August (16.08), but is now frameworks5 based from the December > 16.12 release. Just a curiosity. In debian it seems I don't have any indication on slots, so it's not immediate to know whether a package is based on kde4 or framework5. For instance: solitone@alan:~$ apt-cache policy okular okular: Installed: 4:16.08.2-1+b1 Candidate: 4:16.08.2-1+b1 solitone@alan:~$ apt-cache policy kde-baseapps-bin kde-baseapps-bin: Installed: 4:16.08.3-1 Candidate: 4:16.08.3-1 kde-baseapps-bin is the debian package providing kdialog. Is there a quick and easy way to find out whether an application is based on kde4 or framework5, apart from looking at the version details in every application? Thanks again, Davide
