From: Paul Louden <paulthenerd_at_gmail.com>
Date: Mon, 29 Jun 2009 17:24:44 -0500

Al Le wrote:
>
> This would also work for themes. If a theme setting is changed (no
> matter how -- manually or by loading a .cfg) then we can add an
> asterisk to the pre-selected theme (or do some other things that have
> been proposed here). So we can always tell whether the current state
> exactly corresponds to the theme or not.
>

And if a user then changes the setting back? Such as changing fonts,
realizing it doesn't work with the theme, then fixing the font, what
then? We may get users asking "It keeps telling me my theme is modified,
but I don't think it is. What are the theme settings so I can check them
all?" or similar. It's simply a way to introduce unnecessary confusion
for users who know just enough to get themselves into trouble.

>
> This is probably because themes are rarely changed and there are not
> that many of them. So even if the current theme is not pre-selected,
> you're still not lost. For fonts, it's not so.

Some users change their themes regularly (some have reported changing
themes many times a day) and have dozens of themes, probably more than
fonts, because many themes come with variants. On third-party sites
there are a few theme packs containing many variants of a single theme,
often each with their own .cfg.

>
> I agree that it's not that critical for themes, but I think it would
> make the user interface more consistent. Another question is whether
> this consistency is worth the binary size increase etc.

Consistent with what, exactly? Right now it's consistent with browsers,
which is good because we call it a browser. Changing it like this would
make it inconsistent with browsers (obviously) and inconsistent with
settings (because settings don't change multiple things, nor do they
show an asterisk when modified). It would be special casing it to be
inconsistent, rather than leaving it as it is already consistent with
something, and clearly a member of that group.
Received on 2009-06-30