Is there a graphical GUI builder?

[Chris Angelico]

On Wed, Feb 20, 2013 at 8:34 PM, Roland Koebler <r.koebler at yahoo.de> wrote:
> Hi,
>
>> That way of building a window tends to produce programs that port
>> badly to other systems.
> hmm, I don't think so. I've build several applications in C + GTK/Glade and
> Python + GTK/Glade, which easily run on Linux and Windows without any GUI
> changes.
>
>> playing with Java applets introduced
>> the novel and somewhat strange idea that your window should be built
>> using rules and layouts, to avoid problems with button sizes, fonts,
>> etc, etc.
> Do you know the container-concept of GTK+ and Glade?

Yes, I do; it's just that I first met that concept when I started
playing with Java applets. Up until then, all my UIs had been either
textual or laid out with pixel-based positioning in a WYSIWYG layout
editor.

> In many GUI-builders, you set your widgets to fixed positions (e.g. a text
> field at x16/y16 with 100*30 pixels, a button at x16/y50 with 100*50 pixels
> etc.). This is *bad*, and causes all kinds of problems with e.g. different
> window- or font-sizes, like widgets outside of the visible window, text
> running over the border of a widget or being cut at the edge of the widget
> etc.
>
> But: GTK+ has a wonderful concept of "containers" [*]. You normally don't
> set widgets to fixed positions -- instead, you add layout tables (or
> vertical boxes or horizontal boxes or ...), and essentially define
> that some widgets should be above each other, side by side or in a grid
> layout, so you more or less define the layout logically. The real size
> and position of the widgets is dynamically calculated by GTK+, so they
> always have the right size, and different font sizes, different window
> sizes, etc. are not a problem anymore [q]. And Glade (the GTK+ GUI builder)
> works exactly that way.

Precisely. That's the fundamental difference of thinking. I haven't
actually used Glade, preferring to lay things out myself in actual
code, but the difference isn't so much between "visual layout editor"
and "code to create stuff" as it is between "pixel-positioning" and
"rule-based layout". And it's that difference that creates the
distinction between programs that look terrible on anything other than
the programmer's own system, and those that look fine on any platform.

Same thing happens with web browsers, too, except that they're a lot
more likely to be flat-out buggy (I do not EVER want to go back to
making a web page look correct in IE6).

> [*] Besides, the container-concept also allows such nice things like
> putting anything inside a button (e.g. 2 images and a label), or inside
> a notebook tab etc. pp.

Not that you'll actually *use* that flexibility very often, but it
sure is nice when you want it! And it's a cleanliness of design, too;
instead of having the PushButton subclassed to be the ImagePushButton,
and having the Notebook have special code to permit you to put an icon
on the tab, no, you just have the button surface and the tab accept
one child, which can be a layout manager. What if you like how the
image+text button looks, but want the image to take 25% of any spare
space and the text to grab the other 75%? I've no idea if that level
of flexibility will EVER be wanted, but you can do it with an Hbox
layout manager, so you can do it on a button.

It's a huge change of thinking, if you've grown up laying things out
on pixels. But it's SO worthwhile.

ChrisA