Al Le wrote:
>
> Then the asterisk should disappear IMO. I.e. the "dirtyness" should be
> computed every time.
>

This would introduce even more complication, since you'd have to either
store the values, or re-parse the theme .cfg file each time the browser
was entered, rather than simply having a "dirty" flag somewhere that's
just enabled when any setting from a certain list of settings is changed.

>> On third-party sites there are a few theme packs containing many
>> variants of a single theme, often each with their own .cfg.
>
> He-he, a theme *is* a .cfg :-)

I'm not sure I understand what you mean. I didn't meant to suggest that
they aren't. Variants of a theme can either be a theme in their own
right (and thus, have their own .cfg) or they could be supplementary
files only such as alternative fonts or backdrops to be loaded separately.

>
>> Consistent with what, exactly?
>
> Consistent with the fact that if you select something while in the
> settings, you'll have that item preselected if you visit that setting
> once again.

But this won't be the case. It changes multiple settings (no setting
does this) and if related settings are changed, there's not a valid
value to pre-select so we end up either pre-selecting a false value, or
a stand-in value that may be meaningless or useless anyway. How is that
consistent, when no other menu works this way? It's very much a special
case.

>
>
>> Right now it's consistent with browsers
>
> If you access the theme folder using the file browser then I wouldn't
> expect it to be preselected. But the fact that that menu is
> technically implemented using the file browser code is just a
> coincidence which should not be clear to a regular user.
>

So the word "Browse" in "Browse Themes" doesn't indicate it's a browser?
What if we changed it to "Browse Theme Files?" Would that be clearer?
Received on 2009-06-30