[Lithium] Minimise user-level configuration in BunsenLabs?

johnraff · 2018-02-18 08:25:05

Mod Note: split from https://forums.bunsenlabs.org/viewtopic … 280#p68280
-HoaS

Head_on_a_Stick wrote:

...the problem with our desktop is that any configuration is done at the user level...

This is indeed a problem that comes up. Maybe it's time - at least in the long view - to think about alternative ways of setting up the desktop, with the minimum of hard-coded user configs, so that our DM can offer several desktops, any of which would work nicely.

LXDE used to (maybe still does) have some similar issues of tweaking the system config, but Gnome and XFCE, for example, are able to co-exist OK.

Last edited by Head_on_a_Stick (2018-02-18 22:21:47)

malm · 2018-02-18 22:09:18

^ I think this would be a great move.

The XDG base dir idea addresses this with:

System wide config at

${XDG_CONFIG_DIRS:-/etc/xdg}

with an optional user config override in

${XDG_CONFIG_HOME:-$HOME/.config}

I.e. look for config files in the following order:

"$XDG_CONFIG_HOME", "$HOME/.config", "$XDG_CONFIG_DIRS", "/etc/xdg",

https://standards.freedesktop.org/based … atest.html

So, for a different window manager, set $XDG_CONFIG_DIRS to suit.

Reading the man pages:

Compton appears compliant.
Conky does not appear to comply with the XDG base dir spec, but uses /etc/conky/conky.conf and ${sysconfdir} in a similar way
Openbox respects /etc/xdg... and $XDG_CONFIG_DIRS
tint2 does not appear to. I'd have to look into it to confirm.
I guess there is .xsessionrc, .bash*, .Xresources, mimeapps.list, gtk-themes, et al to consider too.

For any tricky cases, a solution could be to symlink from $HOME to /etc/xdg/... or some other place (no booing please ). It would give us the ability to fix things after the iso release or adapt as packages changes.

Sorry for thread-bending.

I completely understand if you don't want to think about this before Helium though. It would need a lot of thought and testing to get it right.

Head_on_a_Stick · 2018-02-18 22:20:30

malm wrote:

Sorry for thread-bending.

No worries, this is an interesting subject so I have split it out into it's own thread.

malm wrote:

I completely understand if you don't want to think about this before Helium though. It would need a lot of thought and testing to get it right.

Yes indeed, I have added a [Lithium] tag, we are too close to the Helium release to consider this.

johnraff · 2018-02-19 05:46:59

Lxsession has some ideas about configuring custom desktop sessions:
https://git.lxde.org/gitweb/?p=debian/l … fb;hb=HEAD

cloverskull · 2018-02-19 16:05:14

Playing devil’s advocate here, but how much configuration maintenance debt are we going to incur doing this? We already have problems getting releases speedily out the door (I use the term we even though I’ve done nothing, forgive me!) but I find something like this conceptually difficult to test and maintain.

I like the idea, nevertheless. I just wonder about the practicality and feasibility.

Head_on_a_Stick · 2018-02-19 21:27:10

johnraff wrote:

desktop sessions

It's an interesting idea but if we changed BL into an LXDE desktop (we could take over that now that LXQt is moving forward) then that would mean adopting more of the bells & whistles of the desktop environments with full session management rather than plain static configuration files and I'm not sure we should be moving in that direction.

cloverskull wrote:

how much configuration maintenance debt are we going to incur doing this?

Not much, once it is all set up to our liking.

It is even possible that an abstraction framework of some sort could actually simplify maintenance but at the (potential) cost of extra running overheads in respect of RAM & processor cycles.

malm wrote:

$XDG_CONFIG_DIRS

I like this idea a lot

I've just tried it out[1] in my BL-He-VM and it almost works:

The openbox theme & menu are loaded but not the autostart file

I will investigate this some more...

[1] I removed ~/.config entirely then added this line to ~/.profile

export XDG_CONFIG_DIRS='/usr/share/bunsen/skel/.config'

and used `startx /usr/bin/openbox-session` from a TTY login.

johnraff · 2018-02-20 08:31:12

I only threw this out as something to keep in our heads and think about from time to time, rather than proposing to go into anything specific yet.

The lxde-session link was as a bit of background reading, not a proposal to base future BL on lxde! Anyway, I've had enough grief in the past with XFCE's session handling to be quite leery of going too far that way.

OTOH, another bit of background, XFCE's startup script: https://git.xfce.org/xfce/xfce4-session … rtxfce4.in

Head_on_a_Stick · 2018-02-20 21:13:02

Head_on_a_Stick wrote:

malm wrote:
$XDG_CONFIG_DIRS
I like this idea a lot
I've just tried it out[1] in my BL-He-VM and it almost works:
https://cdn.scrot.moe/images/2018/02/19/2018-02-19-205426_1280x720_scrot.th.png
The openbox theme & menu are loaded but not the autostart file

I was wrong!

The autostart file is actually loaded just fine (hence the wallpaper) but tint2, pnmixer, conky & compton all fail to start, I have no idea why.

When the missing stuff is started manually we have our desktop with nothing in ~/.config (except for our stock tint2rc which tint2 seems to copy over when it starts):

^ That scrot was taken after removing ~/.config (all of it) and /usr/share/lightdm/lightdm.conf.d/50_bunsen.conf then logging in via LightDM and manually starting tint2.

If I can figure out why the programs are failing to start then this could be a viable option for us to drop user-level configuration without the need for a registry-style daemon to apply our setup

EDIT: the font configuration isn't loaded, fc-match reports the Dejavu versions instead.

Also, I copied the "export XDG_CONFIG_DIRS" line from ~/.profile to ~/.xsessionrc so it would apply to LightDM as well.

Last edited by Head_on_a_Stick (2018-02-20 21:47:02)

malm · 2018-02-20 22:31:51

@johnraff: Useful links. I think we would do well to avoid LXDE and XFCE sessions. Sounds like we've had similar experiences - I have tried both and found them quite intrusive.

@cloverskull: Yes, I agree. It's better to keep it very simple. I.e. a default setup for openbox only.

It might still be worth keeping some config files in /etc/xdg rather than ~/.config/ to allow devs the option to tweak config files after the iso release (lithium+). E.g. /etc/xgd/openbox/autostart rather than ~/.config/openbox/autostart

@Head_on_a_Stick:
How about writing our own session file based on ~/.config/openbox/autostart. Example below based on dwm:

/usr/share/xsession/dwm.desktop

[Desktop Entry]
Name=dwm
Comment=Log in using dwm
Exec=/usr/bin/dwm-session
TryExec=/usr/bin/dwm-session
Icon=dwm
Type=Application

/usr/local/bin/dwm-session

#!/bin/sh

# Clean up after GDM
xprop -root -remove _NET_NUMBER_OF_DESKTOPS \
      -remove _NET_DESKTOP_NAMES \
      -remove _NET_CURRENT_DESKTOP 2> /dev/null

# Set up the environment
A="/etc/xdg/openbox/environment"
test -r $A && . $A
A="${XDG_CONFIG_HOME:-"$HOME/.config"}/openbox/environment"
test -r $A && . $A

## Configure touchpad. See 'man synaptics' for more info.
synclient VertEdgeScroll=1 HorizEdgeScroll=1 TapButton1=1 2>/dev/null

## Set keyboard settings - 250 ms delay and 25 cps (characters per second) repeat rate.
## Adjust the values according to your preferances.
xset r rate 250 25

## Turn on/off system beep.
xset b off

/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
nitrogen --restore &

exec /usr/local/bin/dwm

From https://github.com/johanmalm/.dotfiles/ … enlabs/dwm

This type of setup could be packaged into a .deb file and put in the backports. That way the default iso is kept minimalist and clean.

Using $XDG_CONFIG_DIRS probably wouldn't not work well with the current BL setup, as $HOME and $HOME/.config are full of user-override config files.

Last edited by malm (2018-02-20 22:32:48)

Head_on_a_Stick · 2018-02-20 22:55:48

malm wrote:

It might still be worth keeping some config files in /etc/xdg rather than ~/.config/ to allow devs the option to tweak config files after the iso release (lithium+). E.g. /etc/xgd/openbox/autostart rather than ~/.config/openbox/autostart

Yes, that's the whole point of this thread

At the moment, all of our configuration is held in $HOME and if a new user is created then LightDM is needed to set everything up and copy the configuration files from /usr/share/bunsen/skel

It looks like setting $XDG_CONFIG_DIRS to /usr/share/bunsen/skel eliminates the need to copy our stock configuration files to $HOME (with some caveats) but it won't work for ~/.conkyrc and other files not under ~/.config (and fonts.conf, for some reason).

Anyway, this is all highly speculative at the moment...

tknomanzr · 2018-02-21 01:47:27

^ Truth be told ~/.conkyrc should be moved to ~/.config/conky/conkyrc anyway. Putting it in ~ just offends my OCD. I haven't really looked at the source, but it seems to me that bl-user-setup --refresh does a lot of user setup for us in $HOME? Perhaps this would be a good starting point.

The way that I have set up the new bunsen-exit is that it first looks in
~/.config/bunsen-exit, then
/etc/bunsen-exit, then
/usr/share/bunsen/skel for its config files.

I chose not to move any files into place in this instance because running the program without any config files in place at all results in the program running with a default gtk theme, which some people might want.

I am using the module pyxdg in python that gives programmable access to numerous open desktop functions.
http://pyxdg.readthedocs.io/en/latest/b … ctory.html

We know how to run something on the first login from bl-welcome, so my thinking is that on the first login of a specific desktop, we should check to see if the config files reside in an expected place and if not place them where they should go. Similarly, if a new user is created, then when that user is logged in the first time, a new environment needs to be created.

I am not conceptually opposed to offering a tiler along with a stacker, so long as we can maintain the workload. Given how much tiling I do with Openbox, I might actually have need of a tiler.

johnraff · 2018-02-21 06:06:50

tknomanzr wrote:

~/.conkyrc should be moved to ~/.config/conky/conkyrc

~/.conkyrc is the default location where conky looks for config. We didn't choose that, that's how conky is. Any other location has to be specified with 'conky -c /path/to/file'.
In fact our default ~/.conkyrc (installed by bunsen-configs) is identical with ~/.config/conky/BL-Default.conkyrc (installed by bunsen-conky). Agreed it's messy, but I don't know what we could do about it.

Many programs still put config files directly in ~/, years after ~/.config/ has been preferred.

bl-user-setup --refresh

This does a rerun of the import of config files from /usr/share/bunsen/skel, overwriting existing files but making backups and being more verbose as to what it's doing.

The way that I have set up the new bunsen-exit is that it first looks in
~/.config/bunsen-exit, then
/etc/bunsen-exit, then
/usr/share/bunsen/skel for its config files.

To be honest, I'm uncomfortable with referring directly to files in skel as configs. Actually, a couple of files in skel are templates, which get edited while being imported, but anyway using skel as config just feels wrong somehow. Since /exit is available for package-installed config, does /usr offer any further advantage?

Many programs install a vanilla config file somewhere in ~/ on their first run, copying it maybe from a template in /usr/share/, or sometimes just from baked-in code. Users then can edit their files at will.

If a desktop like BL referred to config files in some system location, then the user's ability to customize would be gone, unless they had optional files under ~/. In that case, such files could not of course be upgraded by packages - only the configs which were still in their default vanilla state. That would still be an improvement over the present setup perhaps.

Head_on_a_Stick · 2018-02-21 08:11:35

johnraff wrote:

If a desktop like BL referred to config files in some system location, then the user's ability to customize would be gone

That's the beauty of the XDG_CONFIG_DIRS method — a fresh user has no content in ~/.config but if any customisation is carried out then that directory is populated and subsequently preferred over $XDG_CONFIG_DIRS

johnraff · 2018-02-22 01:06:05

@tknomanzr my apologies, I haven't been paying attention and conky has changed.

johnraff wrote:

tknomanzr wrote:
~/.conkyrc should be moved to ~/.config/conky/conkyrc
~/.conkyrc is the default location where conky looks for config. We didn't choose that, that's how conky is. Any other location has to be specified with 'conky -c /path/to/file'.

In Jessie, that was the case:

man conky wrote:

Default configuration file location is $HOME/.conkyrc

But now in Debian Stretch:

Default configuration file location is $HOME/.config/conky/conky.conf

So we could forget about ~/.conkyrc
Conky, when launched with a plain 'conky', still uses ~/.conkyrc if there's no $HOME/.config/conky/conky.conf, but the latter will take precedence (just tested).

This is an issue for the Conky Users though. Although the -c option seems to allow any file name, maybe conky config files should be migrated from *conkyrc names to *conky.conf? Our conky management scripts are organized on the basis that every config file's name ends in conkyrc; conky.conf is not recognized, so some rewriting would be needed there.

Sorry, this is wandering off the main topic of this thread...

#1 2018-02-18 08:25:05

[Lithium] Minimise user-level configuration in BunsenLabs?

#2 2018-02-18 22:09:18

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#3 2018-02-18 22:20:30

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#4 2018-02-19 05:46:59

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#5 2018-02-19 16:05:14

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#6 2018-02-19 21:27:10

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#7 2018-02-20 08:31:12

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#8 2018-02-20 21:13:02

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#9 2018-02-20 22:31:51

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#10 2018-02-20 22:55:48

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#11 2018-02-21 01:47:27

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#12 2018-02-21 06:06:50

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#13 2018-02-21 08:11:35

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

#14 2018-02-22 01:06:05

Re: [Lithium] Minimise user-level configuration in BunsenLabs?

Board footer