"Defaults" button in every settings screen

[Nick Schermer]

On Fri, Dec 9, 2011 at 5:45 AM, Andrzej <ndrwrdck at googlemail.com> wrote:
> On 12/09/2011 03:41 AM, Stephan Arts wrote:
>>
>>
>>>> http://wiki.xfce.org/design/profile-manager - there were mockups but
>>>> they are gone now, but this is a related idea.
>>>
>>>
>>>
>>> Interesting.
>>>
>>> I imagine this would be done per xfconf channel, wouldn't it. I wonder if
>>> that's not too coarse approach, and if so, what would be the right chunk
>>> of
>>> configuration to save/restore.
>>
>>
>> Well, per channel would be possible for an 'advanced' configuration.
>> But the primary goal is making it easier for end-users, with
>> property-groups (app or function-based) and 'friendly-names'.
>
>
> From the user's perspective that's actually better.
>
> There are some issues of such fine-grained partitioning we need to be aware
> of:
>
> - who decides the boundaries of these partitions and how do we implement
> them?
>
> Do we just automatically follow the structure of the xfconf property tree?
>
> The link between the dialog box and the xfconf sub-tree isn't always that
> obvious. For example if we wanted to change settings of a single launcher in
> the panel, we'd first have to know its ID (which may change) and then
> save/restore properties matching the pattern:
>
> /plugins/plugin-<ID>/*

Plugin-id's never change.

> Restoring these setting would fail if someone had previously rearranged
> plugins in the panel. To this work we'd either have to make the IDs
> immutable or hard-code some application specific logic in the save/restore
> mechanism.
>
> IMHO, saving/restoring the whole channel is the safest bet (properties are
> only guaranteed to be consistent at this level). In the example above, that
> would change settings of all the panels and their plugins at once - less
> flexible but simple to think.

Per-module is better, where each module ships a file (or maintainer in
the profile-manager) where settings are stored. For example the
xfce4-panel xfconf config is useless without content of
~/.config/xfce4/panel and keyboard settings has properties in 2
channels (some for a lot of other xfce4-*-settings plugins).

> - What if there are cross-dependencies or conflicts? (some options depending
> on the compositing being enabled etc.)

The code should protect that, not the setting in a channel.

Nick