[PartialGestalt]

A few low-priority feature requests for addon settings...

1. Comparators by id, rather than position
I really like the basic idea for showing/hiding settings in settings.xml using the comparators (eq(), lt(), gt()), but using the relative offset can get awkward pretty quickly with larger numbers of settings, or if you need to add or remove settings somewhere in the intervening spaces.

2. fileenum paths
If we have a setting that uses fileenum, is there a way to refer to a path outside the profile/addon space? If an addon is associated with a third-party tool or application, this would be nice. Also, would it be reasonable to merge paths if multiple items were given in the "values" attribute? For example, a system-wide directory merged with a per-user directory.

3. Per-category or per-setting descriptions
While good UX dictates simple and clear labels, sometimes the opportunity for more description might be helpful, for either individual settings or categories.

Thanks for the great work!

[ronie]

1) it's part of this PR: 1007 (PR)
see: [Addon Settings] move to supporting visibility conditions

3) you can add a description using the 'lsep' type:

Code:

<setting label="30320" type="lsep" />

[PartialGestalt]

Ronie,

Thanks for the update -- that PR looks like it takes care of a couple of other things, too.

Sorry about missing the 'lsep', don't know how I missed that one.

[sphere]

Regarding 3, personally I would prefer something like this: Settings help / user-friendliness.

[PartialGestalt]

Sphere,

I had only been thinking in terms of how the addon author would add the info to settings.xml (like adding a string id reference attribute) rather than the presentation, but that was definitely a thread I can get behind.

As for presentation, I'm not sure what the best mechanism would be...popups would definitely waste less screen than in-place, but you'd still have to have something indicating that help was available (unless we relied on the user to just know to hit the 'info' button), and that risks cluttering the interface. Also, there's the added complexity that you'd have no obvious way to get supporting text for the values themselves -- e.g. what does a boolean "true" mean for setting X, or what does option Y mean in a selection? The precedent exists for in-place descriptions on the main system settings page (the help area shows detail for the current menu item), so it wouldn't be too jarring to have in-place text, either.

Maybe there's some perfect mechanism, or just punt and leave it up to the skinners, I don't know....