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.
