I'd like to butt in with a question here, with apologies for whatever obvious things I may be missing (that I hope someone is also willing point out):

Why is it not already possible for the persistence feature to save/reference the .config directory and everything in it (and whatever other config directories in the home directory)? And of course load these saved settings at startup?

There's always the threat of a user changing a config file in a way that breaks security; however I'm not sure what the best thing to do to would be in order to command the more sensitive programs to store their settings separately. It might just be correct to leave the responsibility for those kinds of fumbles up to the user anyway.

Am I totally wrong that this is the simplest way for any user to save settings?

ghostlands


On 2016-07-27 18:58, Ulrich Viefhaus wrote:
I didn't test using ~/.dconf as you are suggesting, but only by reading
your documentation, it's not clear to me how it works. Dotfiles only
work for *files* (and not for *folders*). So which file should be
included in the Dotfiles? Also, will this file store all changes made to
the GNOME configuration without allowing the user to choose which
changes are made persistent and which not? Would these be binaries files
or would it be possible for the user to review what's being changed?

ALL changes to the gnome settings would be persistent,
if the folder is made persistent. Thats because the newer dconf system
saves all settings in a binary file, thats optimized for reading. The
older gconf system used a xml file for each program.
That makes it a little bit harder for the user.

For example, on my own setup, I made the ~/.xsessionrc file persistent
using Dotfiles and added lines of gsettings commands to it. This way I
can opt-in for which changes I want to make persistent and also review
the sum of my changes.

If feel like these are two very important properties (opt-in +
reviewable). But I'm not very knowledgeable about GNOME internals so
maybe there's a better option than .xsessionrc.

I agree with you. I'm going to brainstorm a little bit in the following
parts, but I think I have an

It is possible to watch all changes by calling "dconf watch / > logfile"
at the beginning of a session. This way you can directly see, then
something changes. But evolution and other programs produce some noise
there. I don't think this can be used for opt-in or review.

An other possibility is to use the command "dconf dump / > dump.dconf".
It shows all changes made by the user and saves them to the dumpfile.
This file could be made persistent. You can load it at the beginning of
a new session with "dconf load / < dump.dconf".
But it also contains a lot of noise like this:
        [apps/seahorse/windows/key-manager]
        width=1366
        height=702
It would be quite troublesome to figure out which lines to keep.

But you could save changes directly to a dotfile. The structure is quite
simple, if you already know the command for gsettings.
For example, you could save the following as a dotfile and load it with
dconf load, to change the folder view of nautilus:
        [org/gnome/nautilus/preferences]
        default-folder-viewer='list-view'
The gsettings command would be "gsettings set
org.gnome.nautilus.preferences default-folder-viewer list-view". There
exists documentation about writing such "schemes". Or you can dump
single settings with the dump command and append it to your config file.

You can then save all your settings in a dotfile and load that with
dconf, then the persistent memory is loaded at the beginning of a
session.

I admit that it is not easier than your .xsessionrc method. But I think
it makes it a little bit more clear to the average user, if he/she has a
configuration file with a clear syntax dedicated to such changes.


Kind regards,
 Ulrich


_______________________________________________
Tails-dev mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
_______________________________________________
Tails-dev mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
[email protected].

Reply via email to