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
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> Tails-dev-unsubscribe@???.
