Re: My GEP 2 (metatheme) thoughts

[Bill Haneman <bill haneman sun com>]

On Fri, 2002-09-27 at 19:27, Seth Nickell wrote:
> On Wed, 2002-09-25 at 14:19, Owen Taylor wrote:
> > 
> > Sorry for the last minute response here; I haven't had
> > a lot of time recently with GTK+-2.2 work and other stuff.
> > 
> > First thought - 
> > 
> >  * Themes are about making your desktop look pretty

???

Themes are about controlling how your desktop looks.  

You might want it to look ugly, judging from most of the themes out
there.

Surely the desktop look includes fonts.  It's fine to have a definition
of the work "theme" that doesn't include fonts, but I don't think that
narrow definition of themes is what we are talking about here.

We already have a "Theme" capplet, recently including window manager
decorations, to cover these 'narrow' aspects of appearance. 

-Bill
...
> > That's not to say that that selecting accessibility options
> > isn't important, or that it isn't related to themes, but if
> > we distort the idea of a theme too much (as a straw man, say
> > having a theme that starts up the magnifier) then we've
> > created a serious usability problem for users without
> > special accessibility themes.

I certainly have not suggested such broad extensions (as starting up
accessibility-specific settings) to these themes.  I agree with Owen
(and Seth) that we should not put things like virtual-keyboard startup
or non-visual settings in Metatheme.  However I do not think that we
have consensus, as Seth keeps assuming, about the role of fonts here;
and on other OS's, font-specification is clearly part of any
metatheme-like utilities' feature set.

Seth, remember that Owen was among the first to suggest as XP-like
metathemer, and the XP utility does control fonts.

>  
> Hi Owen,
> 
> Maciej voiced this a month or so ago, and I'm coming to the same
> conclusion. The interface I design for themes sans the accesibility
> requirements is substantially different from the conclusions people seem
> to be coming to as to a good interface that handles all the accesibility
> stuff. Nils in particular dislikes the inelegant hack I made to the
> interface to secretly allow only accesibility themes to make what I
> consider non-theme-like changes (such as changing the font or font
> size). 
>
> This in my mind all points that the accesibility features we're trying
> to add to the theming system are in many ways orthogonal to theming in
> the non-accesibility realm, and its a critical mistake to try and put
> them both in the same interface. 

I disagree strongly, and don't think a good case has been made for this
conclusion.  

The only so-called "accessibility features" we are trying to add are
font control and background settings, both of which are included in XP
themes.

IN the case of XP, it's clear that these settings are not there just for
accessibility, since they have a separate (though virtually identical,
and AFAICS nearly-useless) "Accessibility" dialog for selecting themes.

> We're collapsing similar but in the end
> very different feature sets together. 

"similar but ... very different" ???

> Inevitably when you have two
> different necessary feature sets one or both are going to be severely
> compromised. The way things are going now, my opinion is that usability
> for the non-accesibility case is being compromised. The proposed
> interfaces are dramatically more complex than what I have proposed
> (which doesn't do the accesibility stuff without a hack).

I believe there is only one feature set under discussion here.
 
> I think the necessary accesibility features should be controlled from a
> preference page in the accesibility section. This would allow an
> interface that's better tailored to user's who need the accesibility
> features, and would allow for the simpler definite state theme mechanism
> without the extra weirdness of tying in things like fonts etc (which
> result in the theme capplet being some sort of meta-setting capplet that
> changes settings that live elsewhere.
> 
> -Seth
>