The widgets in a UI should adapt to different window sizes, font sizes, translated text, left-to-right/right-to-left locales, etc. This is obvious to the programmers that I work with.
I recently remembered that qt-designer didn’t do this when I last tried, which shocked me. So I looked again at a newer version to see if it would make me happier. I took some side-by-side screenshots of Glade and qt-designer on my wide monitor, to make the point.
For instance, see the slideshow to experience the first-impression that a half-competent developer is likely to get. Buttons that were in the corner will be left stranded in a sea of blank space. Widgets will appear half out of the window.
All of this is unnecessary. qt-designer/qt-creator can actually do proper automatic layout if you right-click on the layout, and choose the “Lay out” -> “Lay Out in a Grid” menu item. The default is called “Lay Out in a Form Layout”. Presumably someone decided to make Visual Basic users feel at home by duplicating their stupid environment, but that just keeps them doing stupid things and makes regular developers go elsewhere.
By the way, I do like one thing in qt-designer more than Glade. It correctly assumes that a treeview is more likely than a text label to need to expand.
Note that qt-creator, which uses the same system, apparently via the same code, does the same thing. I checked the latest qt-creator snapshot.
I think the reason it works like this is that you’re first allowed to loosely slap your interface together. When you’re done doing that you start grouping controls in individual (sub-)layouts. I find it to be very intuitive.
Visual Basic is not the problem. It is the Win32 API. If you use Visual Basic 6 or Visual Basic.NET with System.Windows.Forms, you will get the same results. Same with writing your app in C on Windows.
However, there is a new GUI API called Windows Presentation Foundation that you could use Visual Basic.NET or another programming language to create automatic layout.
Again, it is not Visual Basic – it is the Win32 API that does not do automatic layout – it was not designed this way. When Gtk+ was created, it had the fortune to use existing automatic user interfaces like HTML and Java’s AWT as inspiration.
I think the reason is that Visual Studio (AKA the most popular RAD IDE in the world .. no arguments here) behaves pretty much the same – it lets you drop components in random locations and if you resize the window you get your widgets trimmed. An “Experienced” VS user would use the layout containers and anchors.
Just like you, I think that this default is stupid BUT…
It contributes to the first “wow” effect:
“Look, I just drop a button, click it and write MessageBox.Show(“hello world”); and press the silly green triangle”
With open source tools (except for FreePascal+Lazarus maybe) it’s more like:
“Learn how to properly use layouts or switch to use absolute position layout , write code in your IDE/Editor, connect the signals, compile, execute”
The thing about using layouts is that it forces you to use your brain (which might lead to an massive brain explosion for some VB programmers) and plan your GUI carefully…. which is a good thing.
OTOH, if you are prototyping some program, the GUI-design-correctness is (usually) the last thing you take care of and in this case, absolute position feels more natural and more intuitive as Ingmar Steen mentioned.
No, the reason is that it is way simpler to drop widgets onto the canvas an add the layouts later than the other way round. Just try it.
If you start with an empty form then you got what you asked for: an empty form. If you prefer to start with a layout why not choose one of the may form-templates rather then the empty form? The mother of UI-designers, Delphi, also allowed empty forms. Why should they be denied?
I believe I started with a dialog. Whether the form has widgets on it already is orthogonal to the layout system that it uses. You can have a blank “form layout” or a blank “grid layout”.
Glade allows non-automatic positioning via the GtkFixed container, but it’s not pushed at you.
Although Glade still fails here by not encouraging scrollbars, hence the number of UIs that are limited to arbitrary screen heights and are unusable on netbooks. (For example, Evolution’s first run wizard).
We forget too often, especially with GTK: Layout containers don’t do everything :)
If Scrollbars are a sane emergency solution for when UIs are too big for the screen then surely that should be done in the toolkit, maybe in GtkWindow. Having them explicitly in every window, just in case, would be tedious.
It would probably be more useful if Glade just made it more obvious when your UI is too big for certain screen sizes, with typical themes.
Designer does not have any “default” layout. By default there is no layout when you start creating a window. The assumption is that depending on the content you plan to add to your window you will choose a different layout (grid, form, vbox, hbox, vsplitter, hsplitter).
The form layout is actually a very nice layout when you want to create a series of label + widget column. It is a very nice layout because it takes the platform into account: for example if you are on gnome it will left align the labels, if you are on kde or mac os it will right align them. See http://doc.qt.nokia.com/4.7/qformlayout.html for more.
Ah, so maybe “Form Layout” doesn’t mean what I thought it means. But saying that there’s no layout by default doesn’t really make it any better, particularly when there’s no suggestion in the UI that you should choose one.
Regardless of what poorly-named concepts are in use, the first impression is the same. And first impressions can’t be explained away.
I agree with you it is a bit confusing. I have helped quite a few developers learning Qt who were having difficulties to get their widgets to correctly fill their window. They would often be successful at grouping several widgets together in a layout, but would fail to add a layout to the toplevel widget itself. I don’t think however setting up a default layout would be a good idea, but I have no better one at the moment :/
I don’t use QT … i am a gtk+ fan. I’ve been using glade with a complex aplication and what i need the most is to simulate my interface, and there glade fails.
I think the new interface test window is great to test with different sizes, but if i define a size for a widget, it should be respected even in the edit window, so that i should not have to run my app everytime i change something in glade.
ps: i also have been told that having glade repect the requested sizes makes glade behave badly.
Well, when Tristan finishes his work on the GTK+ innards, Openismus would love some company to pay us for him to implement his various ideas about these things in Glade.
It is kind of curious that the only thing you do like about designer is not even handled by designer: It does not assume stuff about widgets, it just uses the normal Qt layout engine.
I found your screenshots interesting in that designer looks ugly while you were working on the UI… but it did produce a nice looking dialog. Glade on the other hand might look a bit nicer while working with the UI… but the result is really ugly:-)
OK, so something in the label and treeview widgets (or maybe the layout) gives them sensible default expand behaviour.
If I had bothered to fix the expand option for the treeview in Glade the the end result would be the same, except in Glade I wouldn’t have had to find that badly-named option tucked away in a sub-menu of a context menu.
http://www.flickr.com/photos/murrayc/5104068667/in/set-72157625216266374/
Not that I’m saying that it’s easy enough in any UI designer, of course. It’s generally very hard to make dynamic behaviour (and options about behaviour) obvious in a layout that appears static. But qt-designer seems to make things unnecessarily obscure. Qt’s widget/layout separation may be to blame for a little of that, though that would be a whole other circular discussion.
I guess it all boils down to what you are used:-)
Which context menu are you referring to? The layout one? You did notice that all the layouts are available as part of the toolbar, too?
I actually do prefer designer to glade. OK, I only read through the tutorials found here, but that workflow described there is horrible!
With designer I can drag some widgets onto a (usually way too big) dialog and get the basic design of my form straighted out. There is no need whatsoever to draw mockups on a peace of paper! Only afterwards I then start to apply layouts to groups of those widgets. I am basically applying layouts from “the inside out”. This is a iterative process that ends when the form has a layout. The whole thing is very dynamic (no need to add layouts, giving the number of widgets that they will contain at some point! That is just horrible).
PS: The documentation of designer is pretty good, just for the next time you have to use that bloody Qt thing;-)
> There is no need whatsoever to draw mockups on a peace of paper!
Just because some tutorial that you find on the internet suggests that you should mockup UIs before you start, that doesn’t mean that you must. Though you probably should, regardless of what tools you use.
I can see the value of using a fixed layout for mocking things up. But I hate to see this presented as the way to actually layout UIs.
When I first used Qt Designer, I actually found this to be a big advantage. When working on a form, you will most likely not get it right on the first try. It’s much easier to break the layout (or just parts of it), move things around and the apply layouts than trying to re-arrange the layout “trees” you have in Glade. The nice thing is that you don’t even have to try to position the widgets exactly when you want them. The layouters will try their best to guess where did you want the widgets to be (very useful for grid layouts).
Hej, Java AWT and HTML layout came after Gtk+. Even on the Amiga we had layouts in the popular MUI (magic user interface) library (http://www.sasg.com/mui/).
I don’t like it when sites use overly-CONCLUSIVE words like “useless”.