Re: Is 2.2 actually going to ship with accessibility themes
- From: Bill Haneman <bill haneman sun com>
- To: desktop-devel-list gnome org
- Subject: Re: Is 2.2 actually going to ship with accessibility themes
- Date: 02 Dec 2002 18:46:20 +0000
> Message: 4
> Date: Mon, 2 Dec 2002 20:58:46 +1100
> From: Jeff Waugh <jdub perkypants org>
> To: GNOME Desktop Hackers <desktop-devel-list gnome org>
> Subject: Re: Is 2.2 actually going to ship with accesibility themes
>
> <quote who="Sander Vesik">
>
> > How do you propose to accomplish the same thing the large print themes do
> > at the moment? You aren't really solving the prolem if all teh
> > functionailty doesn't stay.
>
> You're assuming that any other proposal would not adequately solve the
> problem... Why would an entire theme just to say "make font big" be more
> efficient than having a simple "make font big" flag in GConf? Especially
> when other systems can reuse this setting far more easily than divining the
> intent of the GTK+ font size.
Hi folks:
Size is not a toggle between "big" and "not big". One of the primary
problems with jrb's suggestion is that it regresses the ability for
themes to specify an actual font size and set of icon sizes, in favor of
a catch-all setting.
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.
Also, it would not meet accessibility requirements for applications to
read a boolean "largeprint" key, since those applications are required
to track "system" font sizes in order to meet accessibility standards.
That means tracking the actual size, not just whether it's nominally
"big" or "normal". Similar issues apply to the matter of contrast and
color.
> 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. If the issue is about how many theme-sets we
include by default, then we should have that discussion. Removing the
ability for a distro to add more with different size specifications is
not the solution, that would be worse than shipping fewer low-vision
themes in the first place.
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).
-Bill
> - Jeff
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]