On Tue, Mar 20, 2012 at 1:01 PM, Peter Hurley <[email protected]> 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 http://live.gnome.org/GTK+/RenderObjects 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 properties. 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. Benjamin _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
