Re: GtkStyle/theme issues with API implications

[Bill Haneman <bill haneman sun com>]

Owen Taylor wrote:
> 
> Bill Haneman <bill haneman sun com> writes:
> 
> > In the gtkrc file, everything is very widget-class-based.  That
> > introduces a limitation for custom widgets... [snip]
> 
> 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.

Yep.  Maybe we can think up something for 2.2 that doesn't cause
breakage of existing themes.
 
[...]

> 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>");

Yes - so then we want to encourage app developers to use Pango markup
for
labels/etc. rather than modifying the styles.

However it is a less convenient API (than one which modifies the style
on a class-wide basis, for custom widgets) in those cases where a custom
widget
wants to use a different size variant from the parent class, by default.

Pango provides standard font 'types', but can Pango be 'themed' so that,
for instance, 'Monospace' means a particular flavor of Courier ?  This
would
be very desirable, but it seems to me that to do it with existing API,
Pango would have to call gtk_settings_install_property
('Pango-font-Monospace').
But Pango can't depend on a piece of GTK API, can it?

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

Cool, I feel a patch coming on... ;-)
we can do the draw_focus RFE very easily this way, with
'focus-line-width' and 'focus-line-style' params.
 
> > ... I think separating font-size and
> > font-family would be preferred. 
> 
> 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().

Cool, see my comment about patch ;-)
 
>  - We need a syntax for font names with unspecified style.
>    "12" is a valid font name, but it means "normal style, 12 point".

How 'bout "* 12" ?
 
> > 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.)

Yeah, how about <size+2>, <size-3>, etc?
 
[...]

> but I assume you mean something like:
> 
>  bg[PRELIGHT] = color-prelight1

Yeah, but sometimes with a color name that was not
prelight-specific, it might be used for other things inside the
theme.  But it would prevent re-ryping RGB triplets and
syncing them when editing themes.

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

Cool, that would be ideal.  A mechanism like that could be used
by custome widgets to create nice effects without totally screwing
up accessibility for low-vision and colorblind users.

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

No, but we can strongly discourage this sort of broken stuff by
giving app authors a more flexible palette of 'standard'
colors in the themes, so that the temptation to break accessibility by
overriding colors and fonts is not as great.
 
[...]

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

I think we made progress already!
 
> 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.

That would be cool, I think adding the ability to internally
reference global property names (c.f. the prelight example above) 
would be even better.
 
> Regards,
>                                         Owen
 Thanks,

Bill