Re: GTK+ scene graph

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 2 August 2014 22:14, Sébastien Wilmet <swilmet gnome org> wrote:
> Hi,
>
> Some questions about the GTK+ scene graph ([1]).
>
> Why not reusing the height-for-width and width-for-height sizing
> requisition type? Will it Just Work with the constraint-based layouts?

first of all, GSK sits at a lower level than GTK, so it cannot reuse
types from the latter. GSK is meant to be used by GTK like GTK
currently uses GDK. it is possible to use GSK directly to create UIs,
but the intent and scope of the API (at least for GTK+ 3.x) is to
allow replacing Clutter, Clutter-GTK, and possibly Clutter-GStreamer
in order to create dynamic and compelling UIs. once we can break API
in GTK+, we will use GSK to implement widgets themselves.

secondly, GSK has two types of layout management:

  * parent layers request and position children layers by using the
size set on them
  * parent layers use a layout manager

the first use case defers all layout management to the layer above
GSK, i.e. GTK+ which already has all the
height-for-width/width-for-height/baseline geometry management code.
we don't want to get rid of that, or overlap with it at a lower level
in the API; that has demonstrably been a bad choice in the past.

the second use case is, by default, going to be driven by parametrized
constraints — i.e. the ability to set constraints that solve the
equation:

  y = m * x + b

where 'x' and 'y' are attributes of the layer, while 'm' and 'b' are
constant factors that can be manipulated through the constraint
interface (and, in the future, directly through UI designers such as
Glade). in spirit, is based on the existing ClutterConstraint design
(which itself is based on the CAConstraint class in CoreAnimation),
but it's integrated with preferred sizes and less reliant on
subclassing the base 'Constraint' class. this system allows you to
specify relations like "position the left edge of this layer at a
distance of 20 units from the right edge of this sibling layer", or
"center this layer alongside the vertical axis that passes through the
center of its parent layer".

this is, obviously, just the default; it's going to be possible to
write layout manager delegates that do something else entirely, but I
don't plan to spend time on this right now.

> For functions like gsk_layer_set_z_position() having 'z' in the name,
> have you considered naming them with "depth" or another more meaningful
> name than a single letter?

yes, it was considered, and no: "depth" (or similar terms) won't be used.

people using a canvas with 3D transformations intuitively grasp the
concept of a Z axis, as well as that of a coordinate on that axis.
they understand rotations around that axis, as well as scaling and
translation.

using "depth" would be confused with the possibility of having "real"
3D objects, with a width, height, and depth.

this comes not only from observing what other canvases with similar
requirements and solution did in the past 10 years, but also from past
experience with Clutter, which used "depth" to mean a position on the
Z axis (this was only recently fixed through deprecating "depth" and
introducing "z-position").

not using 'Z' also introduces inconsistencies in the API naming; let's
say that we follow the (wrong) example of Clutter, and rename
"z-position" to "depth"; what happens to the property that sets the
rotation alongside the Z axis? scaling alongside the "depth" axis does
not make sense, and the same applies to scaling and translation. what
happens if I apply a rotation of positive 90 degrees along the Y axis
around the center of the layer: does the depth axis run alongside the
rotated layer, as the "depth" name implies, or is it absolute, as the
"Z axis" name would imply instead?

the Cartesian system of reference with the origin in the top left
corner and the positive axes emanating from that point work fairly
well, and has been working well for a lot more time than computers
existed.

> I know everybody use x/y/z, but personally
> when I read some "math" code with lots of single-letter variables, I
> find it more complicated to understand. Maybe the API should be free of
> such single-letter math stuff, or if a convention is followed, document
> it clearly somewhere (but there should not be too many conventions for
> single letters, since it's harder to memorize).

my direct experience of canvas users in the past 7 years vastly
contradicts your experience; documentation, obviously, is important,
but it's pretty clear that developers do understand what "Z position"
means, and if we go in the realm of 3D objects, "depth" is another
thing entirely. it would do us, and our users, a disservice to change
the names of these concepts.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[ ] ebassi [ gmail com]