Who has experience with Qt 4 on OS X?
I’ve had pretty bad experiences with wxWidgets. Not that the toolkit itself is bad, but it’s lacking functionality and polish in various unexpected and awkward ways. The biggest turn-off for me is that it doesn’t support buttons with icons. Not only do I want my GUI apps to work well, I also want them to look nice and to integrate well into the environment. On Linux/GNOME, having buttons with icons is almost essential – not having icons just makes the GUI look plain and ugly. On Windows it can make a big difference as well when it comes to UI aesthetics. The wxWidgets developers commented that they won’t implement this because not all platforms (e.g. Windows) support it. I personally think this is nonsense – Delphi has supported buttons with icons since version 1.0 (for Windows 3.1). Besides, why not just implement it on platforms that do support it, and document it as such? This is already the case for things such as the flat button style.
Another thing I don’t like about wxWidgets is how it forces one to build the GUI top-down. One must first construct a parent container before one can construct child widgets. It’s not possible to construct an invisible child widget and then later on attach that onto a parent. This seems to be a design decision influenced by limitations in Windows.
wxWidgets also has the tendency to layout the GUI differently on different platforms. I usually develop wxWidgets applications on Linux, and port them to Windows later on. What usually happens is that the GUI looks fine on Linux, but totally breaks on Windows – buttons being laid out differently, controls that have the wrong size, etc. I usually end up having to fix the GUI code for Windows. Apparently wxWidgets has different layout implementations for different platforms, and they behave subtly different ways.
The list can go on and on. But generally, wxWidgets feels clunky and awkward except for simple and standard user interfaces without a lot of dynamics. The differences in layout and resize behavior on different platforms seem to be bigger than the differences in CSS implementations in different browsers (with the exception of IE of course).
Qt 4 seems to be a good cross-platform GUI toolkit and doesn’t suffer from these issues. It looks very nice on Linux. However, I’ve seen Mac people flaming Qt for looking “totally miserable” on OS X. I couldn’t find any screenshots of Qt 4 on OS X so I can’t confirm whether that’s true. Does anybody have experience with Qt on OS X, and can show me some screenshots?
Tore Darell said,
September 29, 2008 @ 12:43 pm
I guess I’m biased, being an Ubuntu guy and all, but I think Qt looks horrible on any platform
It’s probably the primary reason (along with the gazillion useless features) I hate using Opera. Have you considered Gtk? I do have a feeling that too will look horrible on OS X though..
Found a screen shot: http://gtk-cocoa.sourceforge.net/Gtk+-Cocoa.jpg – Not as horrible as I thought, but to a Mac user it would probably look and feel completely foreign..
Hongli said,
September 29, 2008 @ 12:55 pm
Yes I have. I like GTK a lot, but apparently Mac people have nothing but bad things to say about GTK: http://www.reddit.com/r/programming/comments/7392g/gtk_on_osx_is_finally_available/
Tore Darell said,
September 29, 2008 @ 1:08 pm
And they’re probably right.. On Linux Gtk looks and works great, it feels native, solid and is easy on the eye, but it uses a completely different paradigm from OS X. I guess that’s the major problem with most cross-platform UI toolkits.. Firefox’s XUL/Gtk integration is only now becoming acceptable to me for everyday use, and it still feels like it’s going to fall apart when I click a button.
VZ said,
September 29, 2008 @ 2:47 pm
[disclaimer: I'm a wxWidgets developer]
I was pointed to this post by someone who asked me whether the problems you pointed out it in wxWidgets were really valid and, well, all I can say is that I’m really puzzled as to how did you arrive at them. Briefly:
- wxWidgets doesn’t support buttons with both text and bitmaps because they’re not part of native LnF neither under Windows nor Mac (the latter does have the native equivalent of wxBitmapButton which is used there, and the next version of will also implement support for such buttons under the former now that Vista has finally added them and so there is a native LnF for them). Delphi buttons are trivial to implement if you need them but they look ugly and just scream amateur. Finally, wxWidgets does support (stock) buttons with bitmaps under GTK+ since a long time so the linked screenshot could well have been implemented using it.
- You can construct child widget under one window and then reparent it under another one. It’s true that you can’t create a child _window_ without any parent (under any OS/toolkit AFAIK) but you can construct the C++ _object_ corresponding to it and only Create() it once the parent is known. This is atypical as the top-down GUI creation is certainly the norm but not impossible by any means.
- wxWidgets has a single layout mechanism for all platform called sizers. If you can produce a layout using sizers which looks right under Linux but is broken under Windows, please let us know (but I’d be surprised if you managed to do it). OTOH if you use absolute positioning then your layout will definitely be broken (in different ways) anywhere but well, this is the case of getting what one deserves.
Qt does have advantages compared to wxWidgets, although IMO they don’t compensate for the main advantage of wx which is its use of native widgets. But the above ones are not among wxWidgets drawbacks.
VZ
Hongli said,
September 29, 2008 @ 3:20 pm
Hi VZ, thanks for responding.
It’d really like to know why you think Delphi buttons are ugly. The standard Delphi icons *are* ugly, but with the proper icons, they look fine to me. In fact, I use GTK icons in my Delphi applications. There’s no native LnF, sure, but what’s stopping you from implementing it by drawing the icon on top of the button?
But interesting, I reviewed the wxButton API again and I now see that it’s possible to create stock buttons. I guess this is good enough for most purposes on GTK 2, though ideally I’d like to have buttons with icon + label on Windows as well.
As for layout, I’m not talking about fixed layout. I’ve always used sizers. The thing is they behave slightly different in undocumented ways on different platforms. I haven’t been able to pin down the exact differences. But I once encountered the following case: I was trying to create a panel within a tab. The panel would contain a list control on the left and a grid control and HTML widget on the right. The layout worked properly on wxGTK, but once run on Windows, all controls would align to the top left, overlapping each other. It took me a while to fix that. I don’t remember what exactly caused this problem, or how I fixed it. It *seemed* that I made a mistake in the layout code. Granted, it was probably my fault, but it would have been nice if wxWidgets showed this problem on wxGTK as well so that I can fix everything on Linux, instead of having to fix something on Linux and other things on Windows.
I’ve run into such layout problems several times.
Another problem that I’d encounter often is related to resizing dialogs. I can tell GTK that a dialog is non-resizable. GTK would automatically resize the dialog based on the recommended size information provided by the widgets. wxWidgets doesn’t seem to have a way to do this in a clean way. For example, a while ago I was writing a simple image viewer. One starts an image viewer in a directory, and it would display the first image on that directory. Upon pressing Page Down, it would display the next image in that directory. I want the dialog to be as small as it could be, while still displaying the entire image. So when the application is displaying a 200×200 image, I want the dialog to resize to 200×200, plus some additional space for status bar that’s in the dialog. GTK can do this automatically, but with wxWidgets I have to call Layout and a few other methods manually. Furthermore, wxWidgets seems only to be able to grow the dialog. I couldn’t find a way to shrink the dialog to a minimum size. So if the application was displaying a 400×400 image and is now displaying a 200×200 image, it would remain to be the same size instead of shrinking.
It’s all about little issues like this. These experiences apply to wxWidgets 2.6 and 2.8.
VZ said,
October 1, 2008 @ 2:25 pm
Delphi buttons: in the simplest terms, they’re ugly because Microsoft doesn’t use them. For better or worse, the native LnF under Windows is the one of Microsoft applications (even though Office ones can be very, very different from stock Windows ones). So Delphi buttons do look out of place, possibly also because they were very widespread in very old Win16 apps.
Layout problems: difficult to comment without knowing what the exact problem was but in general it’s true that it’s very difficult to make sure that invalid code fails in the same way everywhere. We use asserts as much as possible to help detecting this but we only really [try to] guarantee that correct code works correctly under all platforms, not that incorrect code fails everywhere. In the case of sizer layout I’m still very surprised that you had such discrepancy though, again, if you can reproduce it in a simple example you should consider reporting it as a bug in wx.
Dialogs: of course wx does have a way to do it, simply call SetSizerAndFit() instead of just SetSizer() for the top level sizer in your dialog. The dialog doesn’t need to be resizeable for this to work, although it works even if it is, of course (it will be possible to resize the dialog to be larger but not smaller than the fitting size). Maybe you just needed to use wxSizer::SetItemMinSize() for your image window (assuming it doesn’t implement DoGetBestSize() itself properly), again, difficult to say more without knowing the details.
Alex said,
October 8, 2008 @ 8:36 am
If you’re going to develop an app on OSX, you need an OSX native interface. The average quality of OSX interface design and the degree to which the Human Interface Design guidelines are followed means that any one-fits-all solution is going to feel awkward and clunky on OSX. OSX users are also far more picky about their apps. Camino only exists because Firefox’s OSX interface is a non-standard kludge.
Hongli said,
October 8, 2008 @ 10:25 am
Alex, I understand that OS X users are picky about UIs. But what’s wrong with creating such an app with a cross-platform toolkit, while maintaining several branches of the same app, each branch with minor UI optimizations for the target platform? That’s still easier than writing the entire app from scratch for OS X.
Daniel Lyons said,
December 2, 2008 @ 7:12 pm
Psi, the Jabber messenger, is a cross-platform app implemented in QT and I used it on my Mac for years. It looks fine.
Cocoa programming is more fun than QT programming, but it’s definitely not cross-platform. GNUstep is far from complete, to say nothing of the new Mac APIs that aren’t implemented. But people have been making Mac apps in other toolkits for years without anyone being able to tell the difference. Take REALbasic, for example. My former employer, Matterform Media, makes Mac software using RB and nobody could tell it was using Carbon instead of Cocoa unless they were a programmer and went digging around inside the bundle.