Re: [RFC] supporting an alternative layout management algorithm

[Behdad Esfahbod <behdad behdad org>]

Paolo Bonzini wrote:
> Hi everybody,

Ha Paolo,

CC'ing gtk-devel-list.

> I am trying to bring "stack-flow layout" (see
> http://code.whytheluckystiff.net/shoes/wiki/StacksAndFlows for more
> info) to GTK+.  If you do not want to read the linked page, the idea is
> to have a UI made of standard GTK+ widgets, but organized in a
> document-like way with vertical scrolling capability.
> 
> The system is different from what GTK+ uses for its geometry management.
> Stacks and flows are similar to GtkVBox and GtkHBox respectively, but
> they do not match well with the GTK+ concept that widgets have to
> provide their final size before you lay them down in the window. For
> example, a flow is basically a GtkHBox, but its content can wrap: see
> this picture:
> 
>   http://smalltalk.gnu.org/files/gtk+/layout.png
> 
> There are then two main differences: 1) the four buttons are in the same
> flow, but they wrap to the following line; 2) if an element of the UI
> causes a flow to have more width than it requested, the flow can benefit
> of the extra width and use it to avoid wrapping.  Avoiding the wrapping
> may mean, in turn, being able to use less vertical space than it had
> requested.
> 
> The last point is particularly important, because a stack knows that,
> and indeed only allocates to a flow the space that it needs.  This maps
> in my implementation to different semantics for the requisition and
> allocation phases:
> 
> 1) while the requisition phase uses the same GtkRequisition struct,
> right now only the width information is used, to place an horizontal
> scrollbar if needed;
> 
> 2) the allocation phase is given substantially more freedom.  The
> widget/container can modify the GtkAllocation struct to tell the parent
> how much horizontal space it has actually occupied (it must be less than
> what the parent puts in allocation->width), and how much vertical space
> it has needed (which can be any amount >= 0px).
> 
> My implementation uses a new interface, GtkLayoutable, that is
> implemented by all widgets (my system does not require right now
> modifications to Gtk+, though I'd be happy to see it integrated; and in
> that case, with only two available slots in GtkWidgetClass, I guess an
> interface is anyway a better match for Gtk+ 2.x?).  There is also a new
> scrollable container widget, GtkManagedLayout.

These changes of your to GTK+ are quite similar to the "ExtendedLayout" work
that Mathias Hasselmann has done previously, though that's not merged into
GTK+ yet.  He also introduces an interface that adds height-for-width and
width-for-height methods for sophisticated size allocation.  That's a more
generic approach than yours from what I understand.  See:

  http://live.gnome.org/MathiasHasselmann/NewLayoutManager

Can you give it a test and verify that it is flexible enough for your usecase?


Cheers,

behdad

> The new interface, GtkLayoutable, is implemented by all widgets, and
> provides an additional pair of size_request/size_allocate methods with
> the semantics I gave a couple of paragraphs above.
> 
> GtkManagedLayout is a GtkBin that is similar to GtkViewport and, like
> most other GtkBins, implements a decorator pattern; it lays out the
> wrapped widget using the GtkLayoutable pair of methods and exposes the
> result of the layout process through the scrollbar GtkAdjustments.  If
> the wrapped widget is a container, and is stack/flow-enabled, it will
> use the GtkLayoutable methods also for its the subwidgets.  If a widget
> (or even a container) is reached that does not support the new system,
> that can be either because it does not matter, as for GtkButtons, or
> because GtkLayoutable has not been implemented yet; but in any case, no
> change is needed to these widgets because GtkWidget provides a default
> implementation of the two methods that delegates to the old system.
> 
> Since existing containers can be modified to support the new layout
> manager, stacks are just GtkVBoxes and flows are just GtkHBoxes.
> GtkLabel also provides its own GtkLayoutable implementation, because if
> it is placed inside a GtkManagedLayout becomes the equivalent of an HTML
> "display: block" or "inline-block" element.  (Here actually comes a side
> question: why isn't a GtkLabel allowed to take all the horizontal space
> that is available to it?)  I also plan to implement the interface on
> GtkExpander, so that the expanded content can be laid out as
> stacks/flows too, and possibly on GtkEventBox.
> 
> The code is available at
> http://www.inf.unisi.ch/phd/bonzini/webdav/gtk-widgets.git/ (together
> with a couple of demos and two other widgets that I use in the demos).
> 
> So, here are my questions.  Bear with me because, believe it or not,
> this is hardly my first project using GTK+.
> 
> 1) Does the above make sense? :-)
> 
> 2) Does the implementation seem sound?  (I'm not asking anyone to look
> at the code, though reviews are very appreciated -- I'm just asking for
> comments on the design I explained above).
> 
> 3) What would the cost be when using it for relatively large interfaces?
>  For example, what is the cost of having a UI with ~300-400 GtkExpanders
> at the same time?  Should I modify GtkManagedLayout to map children
> lazily as they become visible for the first time?  Does it work to
> create a GtkExpander with no child, and add it only when the GtkExpander
> is activated?
> 
> 4) Would there be any interest to integrate this into GTK+?  (I am a
> volunteer so I doubt I will have enough free time to do so -- but you
> never know.)
> 
> Paolo
> 
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>