On 30.06.2009 00:02, Paul Louden wrote:
We now present "Fonts" as if it were simply a setting, rather than a file browser. This distinction is actually beneficial, because changing the font just changes one value (current font) and if that value is changed elsewhere (maybe by loading a .cfg file such as a theme) the font list *should* (I don't know if it does) update to the new currently selected one. In this way it can absolutely show the "value" that is in use.
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.
But you're judging based on your own expectations. The only thing we know is that there have been very, very, very few people asking "Why doesn't it remember what theme I last selected in this menu?" so even people who find it unexpected haven't felt it was actually a problem worth reporting or requesting a change over.
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.
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.
