GtkStyle/theme issues with API implications

[Bill Haneman <bill haneman sun com>]

Hi:

Sorry about the 11th hour nature of this email but we are trying to
sweep everything one last time for accessibility needs.

I admit to still being a novice at the Gtk theming, so perhaps there is
already a way to meet the need I describe below.  If so, please advise!

There are of course two main 'APIs' for theming, one is the
GtkStyleClass vtable and the functions that one can implement there. 
The other is the gtkrc file, where various properties can be set.

In the gtkrc file, everything is very widget-class-based.  That
introduces a limitation for custom widgets, they can't really get much
support from gtkrc-based theming unless they either inherit from a
complex GtkWidget subclass and thus inherit the properties they need, or
the themes of interest have most of the interesting properties set at
the GtkWidget level.  If, as is often the case, custom widgets inherit
from GtkWidget or GtkBin and then do their own thing from there on, they
will have a harder time making use of gtkrc's Gtk+-class-hierarchy-based
properties.

However one wants custom widgets to be able to make use of properties
(color and font definitions, for instance) that are defined on an
"attribute" basis - for instance, to be able to ask for "shadow-color"
or "background-2", or "bold-font" or "monospace font" or
"label-font-medium" and "title-font-large" and "label-font-small", etc.

The new gtkrc format seems to have a few global-like properties
(double-click-timeout, bell_duration, etc.) but I don't understand if
there is a way of adding new ones.  Also, though "font" seems to have
been replaced by "font_name", I think separating font-size and
font-family would be preferred.  Apps that want reasonable control over
fonts tend to override the default styles, which breaks accessibility
for low-vision users; it would be nice if the apps could replace
"font-family" without overriding font size.  It also means that apps
which wanted several sizes for different labels could query global
properties for font-size and adjust accordingly (sort of like Mozilla's
"+2", "-1" strategy for relative font sizes).


Perhaps a syntax like this:

globals {
   double-click-timeout = 42
   bell_duration = 30
   font-size-large = 18
   font-size-small = 8
   font-size-medium = 12
   font-family-text-content = "serif"
   font-family-literals = "monospaced"
   font-family-label = "sans"

<...>

}

What would then be needed is a way to query these properties from
gtk_style_rc_whatever()...
so that custom widgets could get these global properties and use them to
build their internal styles.  This API may already exist, I don't
know... so again "please advise" ;-)

The other potentially really useful thing would be the ability to refer
to named properties within the gtkrc file:

globals {
	Color::fuscia = { 1.00, 0.00, 1.00 }
}

style "my-style" {
	bg[PRELIGHT] = globals::Color::fuscia

[etc.]
}


That would also help promote consistency, and mean that the major
recurring properties (colors, fonts) used by individual widgets would be
available globally.  These two features taken together (global
properties that are gettable by GTK+ clients via GtkStyle API; and the
ability to reference such properties within gtkrc files) would greatly
enhance the ability to create and use consistent styles that custom
widgets could integrate with, while enriching the palette that custom
widgets could draw from.

The font change (ability to query font-size and font-family separately)
would greatly enhance accessibility for users who need large fonts,
while giving a means for custom widgets and apps that want font
customization to do so in an accessibility-friendly way.

It's not too late to do this if we agree that it's worth doing; I would
personally commit to doing most of the work ASAP and we could do via
added API rather than incompatible changes.  The current situation,
unless I am missing some important existing features (and I very well
may be), means that apps and custom widgets either must restrict their
use of custom styles severely, or fail to meet accessibility
requirements.

Best regards,

-Bill