Re: Notes and thoughts on the GTK+ meeting at GUADEC

[Robert Staudinger <robert staudinger gmail com>]

On Wed, Aug 19, 2009 at 1:25 PM, Kristian Rietveld<kris gtk org> wrote:
> On Fri, Aug 14, 2009 at 1:40 PM, Alberto Ruiz<aruiz gnome org> wrote:
>> 2009/8/14 Kristian Rietveld <kris gtk org>:
>> As for theming, I've been discussing a bit with Thomas, Carlos and
>> Cody. We have reached some sort of consensus that a backwards
>> compatible path is possible adding a second vtable for engines,
>> checking the vtable size and working out a structured way to poke the
>> scene graph representation. However, we need time to try these things
>> out. Thomas pointed out that working on a separate theming library
>> makes a lot of sense as it would allow reaching a nice API and it
>> would help the special purpose GObject baed toolkits around to have
>> proper theming as well (say Nbtk, Glitter...).
>>
>> So I think that we've reached the conclusion that theming shouldn't
>> get in the way of the current 3.0 plans, as we don't have time to
>> deprecate GtkStyle and introduce something new all at once
>> (eventhough, we all would have loved to make it).
>
> Great to know that progress is being made here.  Trying things out
> definitely sounds like a good idea.  Even though we are now not
> planning to deprecate GtkStyle in 3.0, we should have an idea whether
> "just sealing it" will provide enough flexibility to migrate to
> "something new" at a later stage. I think one of the larger problems
> has been the hard-coded array sizes of the arrays containing GdkColors
> and GdkGCs (but I am not at all an expert on GtkStyle and theming),
> and this limitation should disappear in a properly written accessor
> function.  Are there more pitfalls that can hold us off from a
> successful migration in the future?
>
>> There's the issue of CSS though. Would it be acceptable to deprecate
>> gtkrc's in the middle of the 3.0 cycle in favor of CSS theming files?
>> This is an area where I'm pretty much blind, prolly Robert Staudinger
>> has a better picture than me here, Robert?
>
> Can current gtkrc's and CSS theming files co-exist?

That might technically possible if the consensus was to get 3.0 out
with minimal API churn. What I'm concerned about is two-way gtkrc/css
compatibility though, see (5) -- if CSS was introduced during 3.0 a
migration path could look like this:

For 3.0:

(1) Seal GtkStyle and prune the gtk_style_*() API.
(2) Make GtkRcStyle private to gtk and only accessible to engines.
Not strictly needs but probably worthwile if we have the chance to:
(3) Swap GdkWindow for cairo_t in gtk_paint_*() engines would continue
to work except having to use cairo_t instead of GdkWindow.

Then during the 3.0 cycle when moving toward CSS:

(4) Implement CSS parsing and cascading in gtk.
(5) Create a GtkCssStyle subclass of GtkStyle with a drawing API to
supercede gtk_paint_*(). The new drawing API would not take a widget
pointer any more. This is the point where the existing engines have to
be cut off to avoid impedance mismatch between "old style" and
css-based drawing. A compatibility engine could probably go some way.
(6) Deprecate gtk_paint_*(). At this point we should be able to move
the private GtkRcStyle to the compat engine.

What I have not answered yet is how this would work for 3rd party
apps/toolkits like Firefox:

CSS cascading (the calculation of a style for a particular node) needs
a DOM to navigate. A solution would be to provide an interface, say
GtkDomNode that is implemented by GtkWidget which the CSS backend
relies upon. Then the mimicking toolkits could just create a
"document" (might be as small as a single node, e.g. claiming to be a
GtkButton), ask gtk to cascade the style for it and draw the result
using the GtkCssStyle API.

(It should be possible to implement this 3rd party integration at
gobject level, so 3rd parties can evade linking against gtk+)

Now, back to reality, it seems that the gtk3 theming-related efforts
(GtkStyleContext/Monet/css-engine,ccss) are not very aligned yet.

Best,
Rob