Re: GEP-2 Theme Sets (aka Metathemer)

[Jonathan Blandford <jrb redhat com>]

Calum Benson <calum benson sun com> writes:

> On Fri, 2002-11-01 at 07:22, Jonathan Blandford wrote:
> > 
> > Thoughts?
> 
> Here's my thoughts on how it matches the various requirements.
> 
> - GEP.  With the addition of the "Save Theme Set as..." button, which
> you said will be along later, I think this design broadly meets the
> functional spec with one exception: 'obsoletes need to provide separate
> large print versions of themes'. 
> 
> I know there are still a lot of people who don't want to consider the
> font as part of the theme, so one simple compromise I thought of was a 
> 'use large fonts' checkbox that would scale up the fonts in any given
> theme to some fixed large size (say 18pt).  That would be big enough for
> a low-vision user to get started, and if they did want to make further
> changes they could do so in the Font preferences dialog.

Fonts seem to come up a lot... (-:  I could change it to a toggle button
instead of an 'apply button', but I'm not convinced that that makes any
more sense.

> One other thing that actually isn't in the GEP is the ability to
> specify/over-ride the icon sizes specified in the gtk theme... I don't
> even know if that's possible right now but it would be rather nice, so
> I've added it to the Icons tab in my wee mockup below :)

We can add that later if need be.  I don't think the icon theme
currently affects your GTK+ stock icons.  This probably needs fixing.

> - Accessibility.  When Seth originally proposed the 'theme suggests a
> font and background' idea, he also suggested the addition of an
> accessibility flag to the theme file (the .desktop file in this case)
> that, if set, would apply the font and background automatically without
> the user having to press the extra two buttons.  I'm unconvinced about
> this as it's better to avoid special-casing for accessibility features,
> and of course it's open to abuse by unscrupulous non-accessibility theme
> authors :)  But it's maybe something to think about.

I don't understand why we want the theme to touch the font for a11y.  To
be honest, it makes more sense to me that it wouldn't.  Once you have a
good font that you can read you want everything to use it.  I don't see
a point in over-optimizing for a pretty specialized initial use case.

> - HIG-compliance.  Biggest problem I see here is that anything you
> select on a tab in a noteboook isn't supposed to affect anything on any
> other tabs.  Which, if I understand this design correctly, means the
> "Theme" tab really ought to be detatched from the rest of the notebook
> somehow, as selecting a theme also selects a particular icon theme,
> window border theme and gtk theme.

Yeah -- that's true.  I'm not really sure if it's a huge problem or
not.  I think it'll actually work alright in general, but we may have to
implement it fully before we know for sure.

> If the preview is generated on the fly rather than being a pixmap
> (something like metacity-theme-viewer does, but showing more elements of
> the theme), this probably isn't a problem.  If you want it to be a
> pixmap supplied with the theme, though, it becomes confusing for the
> user when the theme is "Currently Modified" as the pixmap won't reflect
> the changes.
> 
> That brings us back to a debate we had before about whether the preview
> is required at all if the dialog is instant-apply (which is how it seems
> you've designed it just now).  Or perhaps the metatheme-selection part
> should have an Apply button, but the individual elements should remain
> instant apply, which would probably be my preference given the speed of
> theme changes on my Solaris box :)

This is causing me trouble as well.  I was able to make a simple theme
previewer to auto generate an image of the theme code.  However, it does
you no good if you have to switch themes to see it.  An alternative that
Seth proposed is to put a small icon of each theme in the list just like
the Nautilus theme capplet used to do.  Something like
http://www.stanford.edu/~snickell/thumbnail.png
could be autogenerated for each theme and placed in the list.

An alternative is to go to non-instant apply, though I'd be sorry to
lose this feature.

> Anyway, I just had a quick play and here's one possible variation on the
> design that (I think) addresses a lot of these issues:
> http://www.gnome.org/~calum/metatheme.pngg

Hrm.  That's not very GNOMEy.  I would almost want to put the
gtk/wm/icon themes in a dialog rather than that.  The user interaction
there is a lot more complicated, too.