Re: A springs and struts widget for GTK+

[Paul Pogonyshev <pogonyshev gmx net>]

Gustavo J. A. M. Carneiro wrote:
>   Hi, just some comments below.
>
> On Tue, 2005-08-16 at 00:52 -0400, Matthias Clasen wrote:
> > During last weeks gazpacho hackfest here in the RedHat desktop grotto,
> > I started to work on an implementation of a springs-and-struts layout
> > container for GTK+, similar to the java SpringLayout. The widget
> > is not perfect yet, but it is good enough to play around with the
> > concept, so I thought I should make it available to interested
> > parties. The tarball at
> >
> > http://people.redhat.com/mclasen/springs.tar.gz
> >
> > contains a few examples that show how to use the widget. A quick
> > introduction to the concepts can be found here:
> >
> > http://people.redhat.com/mclasen/README.springs
>
>   I am left wondering why this new layout system?  Maybe it's great, but
> why was it introduced?  To solve something that can't be solved without
> it, I suppose?..  Would the current container-based layout system be
> deprecated in the future in favour of this one, or would both coexist?
>
>   I find the current container-based system easier on newbies, although
> this spring layout system does sound promising for more complex layout
> needs.  Moreover, with recent canvas discussions, this layout system at
> first glance looks promising for controlling layout of canvas items,
> especially since the same mechanism could then be used to layout both
> canvas items and regular widgets.

I'm familiar with both GTK+ and Java, more or less.  I find GTK+ design in
respect to GUI superior in most aspects.  Concerning separation of layout
managers from the containers in Swing, this is one thing I never really
understood.  In the end, everyone ends up using exclusively `JPanel's with
various layouts (AFAIK).  There is also `Box', but it is strictly bound
to using exclusively `BoxLayout' and is otherwise no different from
`JPanel'.  Complicated stuff like `JTable' simply dumps the separation
altogether and ignores layout managers.

What I'm trying to say is that container is practically defined by its
layout.  Don't consider the way the children are placed and how many
different containers can you think of?  This separation looks nice but in
the end gives almost nothing but cluttered use of containers where
constraints are untyped and passed as generic `Object'.  Perhaps the only
gain I can think of is sharability of some layouts, but this is a minor
one given that they typically only have a few fields (or else are not
sharable in a meaningful way.)

In GTK+ you can pack virtually anything in a `GtkButton'.  I'm unaware of
a clean way of doing this with Java Swing.  In Java you can switch layouts
on-the-fly (although what would you really need this for?)  But in GTK+
you can just reparent the widgets, even if it takes more effort.

So, I think that separation of layout managers from containers is not
worth it.  Cannot say anything about new canvas stuff since I have never
tried it yet.

Paul