"Defaults" button in every settings screen
nickschermer at gmail.com
Fri Dec 9 07:44:43 CET 2011
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.
>>> 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
>>> 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
> - who decides the boundaries of these partitions and how do we implement
> 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:
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
> 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.
More information about the Xfce