Recently in my copious spare time (i.e. none, being on paternity leave) I've been thinking about doing a Gtk+ container for Gtk3 based on the java GroupLayout layout mechanism. This is a layout system explicitly designed such that it is useful for an intuitive GUI editor (and its not very useful for manual coding). This is the basis for the netbeans form editor (Matisse). For a quick demo (of an ancient version, but you get the point) see:
http://netbeans.org/project_downloads/www/flashdemo/gui_builder2.swf The general approach of GroupLayout is that you separate allocation in horizontal and vertical orientations and for each direction you create a recursive set of groups, each one arranging coordinates sequentially or in parallel. See e.g: http://download.oracle.com/javase/6/docs/api/javax/swing/GroupLayout.html In Gtk+ this would be done as a GtkGroupBox container with two GtkGroup hierarchies (one per direction). With the setup in Gtk3 this should be quite doable. However, there are a few things missing for a perfect match. First of all, what happened to Bug 628902 "Add expand flags to GtkWidget". It seems to have stalled. This would be very useful. Secondly, the matisse layouts heavily feature baseline-aligned layouts, which I think would help gtk+ a lot to reach the next level in gui neatness. The problem with this is that its not enough to just add a baseline property to the widget, because baseline handling must be part of the size negotiation. For example, a baseline aligned hbox with to labels, containing "Y" and "y", clearly would be taller than the maximum height of the two labels. So, we need to change the gtk_widget_get_preferred... APIs to include the baseline. Fortunately these are not set in stone yet, so we have time before Gtk3 is released. Third, rather than hardcoding spacing in containers, matisse is based on adding spacers (gaps) to the layouts. These gaps are either of custom size rigid (basically what we get in gtk now) or flexible, but mostly they are of standard sizes, that are tied to the theme. For instance, it has standard sizes for distance to container edge, distance between related components, distance between unrelated components and distance for indentation. In fact, not only do these distances depend on the theme, but their exact values actually depend on the widgets in questions, such that e.g. the distance between two related buttons could be different than between a label and a related button. I'm not sure the per-widget-type distances are all that useful, but at the very least having the other standard distances available and themed would both make Gtk+ code less riddled with constants, and allow themes that have different amounts of whitespace. As for manual layouting it seems all the java people swear by MigLayout: http://www.miglayout.com/ -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc al...@redhat.com alexander.lars...@gmail.com He's a genetically engineered soccer-playing waffle chef looking for a cure to the poison coursing through his veins. She's an enchanted hip-hop traffic cop who can talk to animals. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
