Mapping physical screens to KDE containments

[Duncan]

Kevin Krammer posted on Sun, 17 Apr 2016 13:03:01 +0200 as excerpted:

> On Sunday, 2016-04-17, 08:46:39, Duncan wrote:
> 
>> Tho I do have a symlink ~/.config -> config just in case something ends
>> up hard-coding the default, as some things invariably do, so the files
>> end up in the right place anyway.
> 
> Wouldn't it be better to not have that symlink and thus be in a position
> to easily identify buggy programs and file reports against them?

Thanks for the reply. =:^)

Yes and no.  Ultimately, yes, it would get the bugs fixed.  From a 
sysadmin's "I just want it to work without problems, and without forcing 
me to try to figure out where it's putting stuff if it's not in the 
default location", however, such a hack is generally the simplest quick-
fix, and since it generally "just works" from then on...

It's worth noting that I don't generally start with such a hack.  
Something makes me put it there to solve a problem somewhere along the 
line, and I've run into a couple such programs over the years.

As I said, however, I wouldn't expect to see that in a kde app, since 
that's almost certainly going to be handled via a common framework lib, 
and a lot of work went into switching those over to the common-desktop XDG 
specs between kde-4 and kde-frameworks-5.

> Such a program would potentially also not honor the non-user-local
> searchlist,
> i.e. in this case $XDG_CONFIG_DIRS which would even be worse.

Finally, it's worth noting that in some cases the problem may be a non-X 
app such as midnight commander (aka mc), which (relatively, compared to 
my use of it over a decade and a half, now) recently switched to the xdg-
spec locations for some of its config.

And these will generally be configured by the distro packager to work 
with the distro's system layout, whatever it is, so the system config 
doesn't tend to be such an issue.

But meanwhile, non-X/non-GUI apps never-the-less still using the desktop-
spec locations can be a bit of an issue when certain XDG_* vars are 
normally locally set/exported not in the system or user's .bashrc and 
friends, but in the local X/KDE start-script, designed (much like startx, 
which IIRC I actually wrap) to be run from a CLI login.  The XDG spec and 
vars are (GUI/X/Wayland) desktop, not necessarily CLI specs, and in the 
normal case can be seen as pollution of the non-X-terminal-window CLI 
login environment.

But having your mc session use different settings when it's run from a 
non-X CLI login, vs. from a terminal (FWIW, konsole, for me) window 
within X/KDE, and not having configuration changes you make in one apply 
to the other, would definitely be frustrating to try to trace down.

I do appreciate mc getting its settings out of the ~/.mc dot-dir directly 
under the home dir, for sure, and arguably, it was a vast improvement, 
which if more CLI apps were to do similar, the XDG_* var settings would 
belong in .bashrc or the like, but so far it's the only one I'm aware of, 
and I'm not sure moving my XDG_* settings to the shell init for just mc 
is what I want to do.

Meanwhile, I don't quite remember what the other app I had problems with 
was, but it was non-kde but X-based, and IIRC qt-based, tho IIRC still 
qt4-based at the time.  I believe it was a media program, vlc maybe, or 
minitube, or one of the several mpd (music-player-daemon) clients I have 
installed.  (mpd, complete with the half-dozen clients I have installed 
and all their not otherwise pulled in deps, is still /far/ lighter than 
say amarok, and unlike an X-based player, quitting X to work in the CLI 
doesn't stop the music. There's a CLI client and several semi-gui/ncurses 
clients as well, so the music can be controlled from the CLI, but mpd 
being a daemon, once it's playing it can continue without a client 
running, and even restart at bootup, if it was left playing at shutdown, 
so it's not absolutely necessary to have a CLI client or indeed, any 
client at all, once the daemon is setup properly.  =:^)

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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.