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?
