Re: Is 2.2 actually going to ship with accessibility themes

[Bill Haneman <bill haneman sun com>]

Jeff said:

On Mon, 2002-12-02 at 19:01, Jeff Waugh wrote:
...
> > Even if the initial 2.2 low-vision themes use a uniform font size
> > as-packaged, it's important to be able to change that size without having
> > to rebuild GNOME.  And of course some users/installations may need more
> > than one "specified in the theme" font size.
> 
> Surely we could have either:
> 
>   a) an actual point size specified in GConf for 'big', or (because you're
>      saying that 'big' isn't the issue)
>   b) an set of point sizes specified in GConf for 'small', 'default', 'big'
>      or whatever?

Mm, three sizes still don't quite fit all ;-) and yet the elegance of
the single size is lost.

The user can already fine-tune font size via the Font capplet; it's the
icon size stuff that's inconvenient (since at the moment it still
requires setting a string in the RC file).  Thus at the moment we still
need a proliferation of RC files to provide the various "LargePrint"
versions.  If we remove the font string from those files, then the need
to keep them coupled to the icon sizes in the RC files, via the ThemeSet
UI, would be even greater.  So not really much improvement there.

Jeff and I chatted on IRC about this a little, I will cut and paste some
from that discussion.  If the problem here is that people don't like the
fact that low-vision-related themes seemingly outnumber the other themes
at the moment, I suggest that there may be better ways to deal with that
than removing useful (even, in some respects, necessary) items from our
distro, and better than removing/reducing the functionality we already
have or potentially have via the ThemeSet capplet.

An edited transcript follows, where I give some explanation for why
we're still coupled to RC files for 2.2, what the icon size stuff has to
do with the font-size, specification, and I give a suggestion for
dealing with the primary object which seems to be the total number of
"accessibility-related" themes in the default ThemeSet list.

We can eliminate the size stuff in RC files _once we get UI and API for
doing the icon sizes_.  But if we do so, there is still a strong desire
to group the two together again somewhere, which would be via the
ThemeSet UI.  Thus we will continue to need multiple themeset entries
for different appearance sizes.

My suggestion in a nutshell is to ship and install all the accessibility
themes, but only to include the HighContrast and HighContrastInverse in
the default ThemeSet list.  (My _preference_ would be to include
HighContrastLargePrint/Inverse as well).  In order to include the
lesser-used themes (such as the LowContrast and Plain "LargePrint"
versions) in the default list, if this is indeed the main objection
people are having, the user might need to "import" them.  It means we'll
need to clean up our import UI a little to make it simple for a user to
"import" one or more of the 'extra' themes, perhaps something like a
filesystem-based importer that by default looks in the
$prefix/share/themes/extras directory or something.  I am not totally
happy with this suggestion since it may make the initial bootstrapping
process harder for low-vision users, but of course individual distros
would be free to make decisions on which themes to include in the
default ThemeSet list, and if this helps address peoples' current gripes
with the theme capplet it would be better to my way of thinking than
trying to simplify or trim it in a way that would fail to meet our
accessibility guidelines and our current best inderstanding of
accessibility needs.

Best regards,

Bill

======= edited transcript follows =======

<billh> jdub: users can fine-tune their fonts with the Font capplet
already which is fine, but there is still a need for one-click
theme-sets with fonts.
<jdub> there's got to be a better switch than theme selection
...
<billh> jdub: I just fail to see where this impacts the user
negatively.  
Whereas I see clear negative impact in making 'large' a toggle.

<jdub> billh: we're going to get lots of people saying "ugh, i don't
want all these accessibility themes that are all the same"

<billh> jdub: sure, but let's address that actual issues [rather than
leap to a solution that limits or eliminates some of the themes].
By the way, the stuff about icons is important,
but it's related for technical reasons, i.e. the only way to specify
icon sizes at the moment is in RC files.

<jdub> right, yeah, icon size in relation to theme size, yeah
gar
that's a harder one

<billh> jdub: this is why for 2.2 we are going to continue to have these
mostly-redundant RC files. 
[e.g. until we have a nice UI for setting the stock icon sizes for
resizeable icons] 
If the issue is too many theme sets, we might be able to address that.  
Notice something too...:
BlueCurve out of the box uses a different default font size from
"community"; so this "branding" kind of theme already has some font
component. Maybe it goes away as soon as you start tweaking your
settings, but do you see my point?

<jdub> i see your point, but i'm not convinced that there isn't a better
way of doing it yet

<billh> jdub: It would be a great improvement if we could use the same
Font mechanism for our one-click accessibility stuff as the rest of the
desktop instead of having the existing weirdness between Font capplet
sizes and the RC-file size.  But to do that we need another grouping
mechanism to help keep icon sizes and font sizes in sync for some common
"starting points" for user config.

That's one of the main strengths/roles of the themeset capplet, it
creates a way of grouping these things together.
In some cases that may be just a whim, in some cases a matter of
convenience, and in a few (like perhaps a11y), of necessity.
I thought we'd agreed on a 'checkbox' toggle that turned
theme-set-fontsize and theme-set-background on and off...that was the
consensus (to the extent that we ever have those ;-)
on the mailing list months ago.  It may not have been everyone's 
first preference...

<jdub> that's what jrb has gone with

...
<billh> jdub: I agree that it'd be nice to decouple the size stuff from
the color/contrast stuff in the RC files.
But that leaves, to my mind, the one-click theme-set doohicky holding
the responsibility for grouping them back together for ease-of-use
reasons. So you go into the Component tab and instead of 11 RC files you
see maybe 4 or 5, but you still need a bunch in the ThemeSet list.
because they are a 'subset of the permutations' available.

<billh> jdub: what bugs you about it, is it just the number of choices
in the list?

<jdub> that, and general cleanliness.
but it's fine for now

<billh> jdub: we may someday want to add more a11y themes, so perhaps
there will be justification for an extra-gnome-themes package someday.
We could improve our import GUI so that a user could easily choose which
ones appeared in their THeme capplet.
So we could ship them, but the user might have to "import" them
according to their preferences, or something.  That would seem better
than excluding useful things that don't consume that many bits, just on
the basis of UI compactness.

<billh> jdub: I still think the HighContrast and HighContrastInverse
themes would be good to include in the default list, they are getting
more use outside a11y at the moment.

========

> Both of these could be modified as the user/adminstrator sees fit, perhaps
> in the a11y capplet. This seems more flexible and better placed than
> defining them in the theme (given that users will not be able to modify
> sizes defined in the themes to their requirements).
> 
> > > Sounds like a quick hack to me (and at this stage, it's a good quick
> > > hack - let's fix it later on).
> > 
> > No, it's a regression from the point of accessibility.  There is no need
> > for a hack when the current solution (i.e. having separate themes for
> > large print) works better.
> 
> (I was referring to the current 'quick hack' of using themes to define the
> font size - good for now, but is it really the *best* way of doing this? I
> understand that it works, that's fine, but are you absolutely sure that we
> cannot do better?)



> > What, then, if some developers want to write additional low-vision themes?
> > And if users want/need to install them?
> > 
> > Also, reducing the number of RC-file component themes in 2.2 requires a
> > new mechanism for setting and specifying icon size sets, which I don't
> > believe we have yet (unless jrb has added this to the capplet).
> 
> There's a 'choose the icon theme' tab in the Themes capplet now, but not a
> 'define a complete icon theme' utility. These don't have much to do with
> fonts. :-)
> 
> - Jeff