Re: GtkStyle/theme issues with API implications

[Owen Taylor <otaylor redhat com>]

Bill Haneman <bill haneman sun com> writes:

> 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.

Yes, this is a bit of a problem. Not one we are going to be able
to fix for GTK+-2.0, however. This is not a new problem with the
introduction of properties, but has always been a characteristic
of the style system.
 
> 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.

Pango provides standard monospace,sans,serif fonts in normal,bold,
bold-italic, and italic. Apps can get size variants by doing things
like:

 gtk_label_set_markup (label, "<larger>Title</larger>");
 
> 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.  

Try grepping for gtk_settings_install_property in GTK+.

> 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.  

My recent changes to PangoFontDescription basically allow this.
The only things that are missing are:

 - gtk_rc_style_real_merge needs to use pango_font_description_merge()
   instead of pango_font_description_copy().

 - We need a syntax for font names with unspecified style.
   "12" is a valid font name, but it means "normal style, 12 point".

> 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).

That's the point of the scale factors in PangoMarkup, it follows
CSS pretty closely. (+2, etc is supported currently in PangoMarkup,
you need to do <larger><larger>Title</larger></larger>, but 
it could added easily enough.)

> 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"
> 
> <...>
> 
> }

Well, we have this, except without the globals {} block.
 
> 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.]
> }

Hmm, no "fuschia" for this exact example, you could do:

 bg[PRELIGHT] = "magenta"

To get the same color. Not particularly useful for color names :-)
but I assume you mean something like:

 bg[PRELIGHT] = color-prelight1

I was already planning to handle setting the default colors via
XSETTINGS; exposing the symbolic names might help with:

 - The XSETTINGS names are supposed to be standardized across
   the X desktop; the GTK+ standard set of color is really
   poorly designed, so we probably won't want to standardize
   on it exactly. Therefore, we'd need some way of synthesizing
   the standard GTK+ colors from a different set of colors.

   (This might imply a need for 

     bg[PRELIGHT] = lighten(color-prelight1)

 - Some themes want completely different sets of colors than the
   standard ones. The major example of this is the Swing theme,
   which is supposed to draw everything with a small set of 
   standard colors which are reused for different purposes in
   different places.

 - We have some color settings that are duplicated across different
   widgets ... in particular, the GtkEntry::cursor_color setting
   will end up being mirrored for GtkTextView and GtkLabel, at least.

Still, I don't quite see how this solves the problem of themes
wanting to use custom color. If some app author decides that they
think that fuschia looks good as a highlight color for their widgets,
they can make all their widgets use 

 acmesoft-highlight

and configure that to be fuscia by default, but that doesn't make
it any more configurable, since nobody is going to no to configure it.

> 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.

Well, unfortunately, as most of these things, the part that is 
going to take time is niguring out _what_ to do, but not doing it. :-)

Never-the-less, most of the features are actually, there, and adding
a few extensions to allow for xsettings-based color names should
be fairly straightforward.

Regards,
                                        Owen