"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