On ons, 2013-02-27 at 21:22 +0900, Tristan Van Berkom wrote: > > How do we assign 5 pixels above the baseline based on this? All we can > > do is give the child more total height (via gtk_widget_size_allocate), > > we have in general no control of where that height will go. The child > > might be expandable both above and below its baseline, but how can we > > "tell" it to only grow above? > > Interesting... taking your previous example of HBox with widgets > A, B, B, and D... let's consider that A & B is in VBox1 and B & D is > in VBox2 > > What you are asking (I think) is how can we determine that VBox2 > can only grow /below/ and that VBox1 can only grow /above/. > > Is this correct ?
Mostly, although there are more complexities. It may grow on both side, but to different extents and with different "speeds". For instance, imagine a multi-line label that is ellipsized and has the baseline setting as GTK_LABEL_BASE_LINE_IS_LAST_ROW. At any point it shows N rows with the baseline at the Nth row, and if you add height it will add empty space below the Nth row, but then when you suddenly fit another row you'll get the baseline at the N+1th row and the height the was previously blow now got moved to above the baseline. > I think this conversation needs a little bit more context (as to how > precisely you plan to layout the groundwork APIs for this), but > here's what I would envision: > > I think that HBox has the responsibility to 'request and set the baseline' > of it's contents (being VBox1 & VBox2) Thats not what I was thinking, but that does seem to make this more doable. However, this means that *all* implementations of size_allocate must respect the baseline when allocating itself. Thats very different from how todays existing widgets work, and a radical break of "API". The model i was expecting is the current one where widgets do whatever they do in gtk_widget_size_allocate() but can report where this would put the baseline. Of course, in practice container widgets outside of gtk+ are not that common, so its possible that we could make sure the gtk+ ones did handle an extended form of size allocation, which would let us do baseline alignment in most cases. Of course, implementing size allocation of e.g an ellipsizing label like the above example with a pre-chosen baseline will be complicated and probably need new PangoLayout APIs... > I'm pretty sure this approach work's in theory, but there's a big > 'gotcha' in play... which is the intrusive 'halign'/'valign' properties > and any properties which are implicitly calculated by the > ->adjust_size_request() and ->adjust_size_allocate() vfuncs. > > Which means the whole thing breaks down if either VBoxes > have a valign property that != GTK_ALIGN_FILL or that > margins or border_width are set... this is a hard problem to > figure out too... it might require that widgets retain access to > the full allocation given them by their parent, instead of the > final allocation stored after adjustments are made. I'm not sure this is a problem. valign will in this case be BASELINE, or we would not do baseline alignment of the child at all. The margins and borders could well be done automatically like now, as long as they correctly modify the baseline that the child get, i think... > Finally, it's worth noting (I'm sure you're already aware) that > minimum & natural preferred_height_for_width() will hardly > ever differ (they will only differ for vertically rotated text, or > perhaps some GtkWrapBox which is oriented to wrap from > top to bottom). Ellipsized multiline strings is another case. _______________________________________________ gtk-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-devel-list
