Re: CSS box model-gtk containers integration

On Tue, Mar 20, 2012 at 1:01 PM, Peter Hurley <peter hurleysoftware com> wrote:
> Ok. My question was more aimed at finding out what the first steps in
> that migration might look like.
The first step that I want to do is redesign the way widgets draw
things. This is generally known by the term "render objects" or
"actors". You can read a summary of our discussions at the hackfest on
The gist of it is to
- get rid of custom per-widget drawing code
- move from an immediate to a retained drawing model
- make this model very similar to ClutterActor, so we can easily
switch to Clutter later.

> GtkAlignment is a simple example. It has 3 basic object properties:
>  - padding
>  - child offset
>  - child scale
GtkAlignment is a rather boring example, because it's essentially
deprecated, as it has been replaced by the halign/valign properties of
GtkWidget. But I'll go with you to explain the concepts.

> So does the next iteration of GtkAlignment that implements the CSS box
> model:
> A) maintain the existing object properties for compatibility and express
> the box model on top of that?
Yes, we are backwards compatible, so the object properties need to
survive. At least for as long as GTK3 still exists. We'll deprecate
them and then do away with them in GTK 4.

> B) additionally expose the child offset and child scale as special CSS
> properties?
> C) do away with the object properties cruft and implement GtkAlignment
> solely in terms of CSS properties?
The general idea is this - and I'm sure we'll have exceptions on a
case-by-case basis, but let's talk general idea:
The properties on the widget describe the intent of the layout of its
contents. The widget then creates actors that express this intent. And
the actors translate to actual drawing with the help of CSS
This means that:
- We will deprecate and probably get rid of all widget style properties.
- All regular properties that specify sizes in pixels will probably go
away (by being deprecated and then removed in GTK 4).
- Theme engines will also be deprecated and removed and all styling
will happen based on CSS.

> D) implement a draw handler and render a background and a frame?
This has been done a few times (like for GtkImage in 3.4) in the
current cycles as a short-term mechanism while the actors aren't done
yet. But I'd only do this as-needed for the themes, because we'll
throw that code away again when we implement render objects.

> Also, where would be the appropriate place for candidate submissions?
> Here on this list or through bugzilla?
For code, never use the mailing list or it'll get lost. But if you
want to hack on it, it's easiest to hang out in the #gtk+ IRC channel.
We do a lot of iterations with fpaste and custom git branches there,
which to me is a lot faster than bugzilla.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]