When there are already several GUI builders for Qt and KDE, why on earth would anyone start another one? It's a reasonable question, and one I'll try to answer here.
I have tried pretty much every GUI builder that has been written for Qt, and I have drawn some conclusions that I hope will be useful for the improvement of these tools. I have some background in this having written a simple GUI builder for Motif a few years back, and in having written a lot of code using Qt and KDE including KDDL which is another approach to simple GUI creation.
I have, in general, found that each of the Qt GUI builders succeeds in one part of the task, but is much weaker in others. What I think is needed is something that is designed from the start to support the best of each system.
EBuilder has excellent support for working with the widget hierarchy using a tree view, and a reasonable property list, however it falls down in the range of widgets supported, the ease with which new widgets can be added, and by failing to provide any graphical way to construct the widget hierarchy (you cannot 'draw' your GUI).
Qt Architect has much better facilities for graphically creating the GUI, but unfortunately is extremely focused towards fixed layouts. This is ok (though IMHO not good) for programs that will only ever exist in a single language, but is unacceptable in a program that will be translated (as is likely for a KDE application). Newer versions of this program add some very basic support for layouts, but unfortunately they do not currently let you graphically construct a layout hierarchy. Qt Architect needs a custom property widget for every class to be supported which means that it is difficult to create automatic tools for adding new widgets to the system, nor does it provide a way to save widget layouts as reusable objects. A final limitation of QtEZ is that it is primarily a dialog editor with no real support for the rest of the GUI.
QtEZ provides a very simply mechanism for adding new widgets (which can be dynamically loaded from shared libraries), but again fails in other areas. The property list while being fairly functional, has no way to add support for custom layouts (like those of QtArch) if they are availble. As I see it, the property list is a generic tool that should be a available for any widget, but custom dialogs for a widget should certainly be possible. For example widgets like KTypeLayout are useless without custom property sheets. The property list in QtEZ is also unfortunately ugly - it's really just the font chosen, but it is very noticable. The final problem with QtEZ is the lack of supported widgets, though I think that is mainly due to it being fairly new.
When thinking about how I would like a Qt GUI builder to work, I find that I want parts of each of these existing tools. I want the tree view from EBuilder, the property lists from both QtArch and QtEZ, and the simply API available for adding new widgets to QtEZ. Finally I want the graphical tools QtArch provides, but I'd like it to provide support for dynamic layouts and maintaining a hierarchy of widgets too.
There are a number of reasons for this:
This is important as structuring a GUI as a tree makes it easy to reuse pieces of a GUI elsewhere. The existing dialog editors often place all of the widgets created directly into the QDialog base widget, this is a bad thing. If the treeview contains both the layouts and the widgets then by building the tree it is possible to both create the views and lay them out in a single interface.
A tree or list view containing all of the properties of a widget is a really useful tool. While a custom property view such as those of QtArch is great, it is also a lot of work. To be most useful a GUI builder should allow new components to be added with a minimum of effort, and by allowing a generic (though possible strongly typed) mechanism it is fairly easy for users to add their own widgets. Allowing custom property sheets too means that you can support widgets with complex APIs, and that you can present the information more clearly when it is possible.
The graphical facilities are of self evident value. I would like though to be able to graphically create dynamic layouts - I don't want to specify sizes directly, I want to specify the hierarchy. Once the hierarchy is known you can use the layout facilities to create a design that will resize properly.
Having a simple API like that of QtEZ makes adding new widgets easier. Giving them custom property sheets etc. still takes effort, but at least you can add your own widgets in a basic way with almost no effort. The simple API also makes it practical to use tools such as sip to autogenerate bindings to the GUI builder with scripts. This would allow simple components to be embedded with no use intervention. This has to be a good thing.
This is important both because of the translation issue I mentioned earlier, and because of the style support that will be in Qt 2.0. When the look of a widget is pluggable, the correct size may depend on the style currently in use.
Solve all the above problems, produce the worlds greatest GUI builder, then take over the world.
Currently implemented features:
You can only create simple label and form widgets right now, though support for real QWidgets is of course the ultimate target. The form widget is just a QWidget with a QBoxLayout inside, it provides access to the orientation and spacing of the layout. Nesting forms works fine, and you can create some fairly complex layouts like this.
You can create plugin component libraries that will be dynamically loaded by KGUI. A test plugin is included to prove the mechanism works, though I've not yet sorted out autoconf stuff for this. Basically a KGUI plugin is a shared library that is loaded using dlopen(3) API. It must define an extern "C" function called init_kgui_plugin() which returns a pointer to a Package object. The demo plugin provides access to the KLed widget in a package called 'Demo plugin'. A plugin can define new types and their editors as well as using the existing ones, so the mechanism is quite powerful. Plugins should be installed in $KDEDIR/lib/kgui or $HOME/.kde/lib/kgui and must have the file extension '.kgp'. The plugin directories can be configured using normal kconfig entries (keys 'SystemPluginDir' and 'UserPluginDir' in the 'Plugins' group). The user plugin directory is interpreted relative to the current users home directory.
Here are the KDE or Qt GUI builders I'm currently aware of: