Re: [RFC] supporting an alternative layout management algorithm

["Diego Jacobi" <jacobidiego gmail com>]

2008/9/2 Paolo Bonzini <bonzini gnu org>:
> Hi everybody,
>
> 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.
>
> 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
>



Hi. I think that the idea of stacks and flows is a good one, also seen
in other toolkits, but i think that it wont be incorporated in 2.x
series of gtk, maybe you would want lo make an upper lib so any
version of gtk can use it and not only the most new ones.

Also Stacks and Flows doesnt follows the naming convention of GTK and
as you say they are just VBox and HBox with an extra property.
So, wont be better to add the feature as a property to VBox and HBox?
set_property(hbox,'wrap',True)
This is handy for large toolbars, when the application is used in low
resolutions, or also for configuration panels to launch the different
tools, or for list of images.
So when the toolbar or a list of buttons has very little width and
instead of showing a dropdown menu, it will wrap the buttons in a
second line (or column for vbox).

About scrollable widgets, is not hard to add the wrapable VBox to a
viewport and set the viewport width proportional to the window width.
For thoose special widgets with presetted scrollbars it may be better
to have them in a separate library. or as a public code.


Also there are some others widgets that would be good to see, like a
GtkDockableArea to move toolbars (or side panels) from one to other or
make toolbars floating easily.
Or a command line for GtkActions for large applications like for a
drawing: for example "line <X coordinate> <Y coordinate>" could launch
the GtkAction "line" with X and Y as parameters. That would be handy
for undo and redo operations and/or for saving an history of
user-interactions and maybe for debuging because it could make bugs
easier to reproduce.

Cheers.
Diego