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.

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.

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.

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

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..