Qt 4 and language bindings

I've downloaded the Qt 4 beta 1 and briefly played with the new Qt Designer, and had a look at what the code generated by the moc looks like to see if there might be any problems integrating slots/signals with bindings.

I much prefer the new Qt Designer UI. I found the old tool very cluttered and hard to use compared with the Apple/NeXT Interface Builder which have had much more experience with - the new one with separate inspector windows looks more similar to IB.

I was surprised that Aaron didn't like it so much as the old one, although he later changed his mind a bit.

When I was developing the ruby rbuic tool I mainly just used existing .ui files rather than create new ones. It was a while before I got round to setting up a new project with Qt Designer. At first I tried to drag and drop widgets from the palettes onto the main window, but that didn't do anything and nothing appeared to happen. When I finally did place a widget, I ended up double clicking on a palette and it got stuck into 'insert widget mode', and couldn't work out how to get it back into 'select things' mode. The new one works with drag and drop as I would expect it to.

The widgets are better in a QListView than a tree. The Qt 3 palettes waste a load of screen space - there's barely room on my iBook's screen to fit it all. Those great long curvy title/tab things to group the different sorts of components are harder to use than a list view (although that is still not as easy as column mode browsing via NSBrowser in Cocoa), and they are *very* big. It would be nice to be able to load palettes of related components into the tree on demand. Then if you have large numbers, you wouldn't have to see all of them all the time.

I personally hate having to double click things, and I'm glad the new Designer doesn't seem to need any of that.

I agree with Aaron about the toolbar edit mode combo box - clicking on a button would seem more natural than selecting combo box item. I would have thought the control could be on the window you're editing, rather than on the Designer main palette window.

With the connecting tool I expected to be able to control drag from one component to another to visually create a connection as in Interface Builder.

I don't know how much the format of the .ui files has changed, I haven't studied them yet. I'll have to see how much code if any, C++ uic tool has in common with the old one. I hope it won't mean starting again for the ruby rbuic and Marco Ladermann's juic tool for java.

I looked at the code generated by the moc to see if it looked as though there were going to be any problems with QtRuby or QtJava, but it looks fine. It's based on a metaObject, just like Qt 3, and slots are called via a numeric id into a table. The various arg types are loaded into a 'void **' array to pass to a slot, which will fit well with the way the Smoke library works.

If they had been based on function pointers like Qt 2, I would have been in trouble with QtRuby. QtJava doesn't do any fancy stuff with slot/signals internals so that should work pretty much as it is.

Overall, I'm pretty encouraged - the code samples looked very much like familiar Qt programs, with everything polished and improved rather than thrown away and so I can't see the changes for KDE 4 being too disruptive..