"Defaults" button in every settings screen

Andrzej ndrwrdck at googlemail.com
Fri Dec 9 05:45:15 CET 2011


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>/*

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.

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

- How do we integrate this mechanism in the GUI? (are the mockups still 
around?).

Andrzej


More information about the Xfce mailing list