hi; On 2 August 2014 22:14, Sébastien Wilmet <swil...@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] _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list