Does anyone here have experience writing GUI code for Haiku who can comment on what it’s like to use compared to other GUI libraries, like Qt, Gtk, etc? What rough edges are there? Is there anything that’s particularly good or particularly bad? Does the event model make sense? Is there anything which is missing which other toolkits have, or vice versa? And so on…
I have some experience with writing native Haiku applications,but no experience with other GUI libraries.
The BeAPI has some similarities to Qt,both are written in C++ and many class names are the same,except the prefix (QApplication->BApplication, QWindow->BWindow, QString->BString) but as I’ve never worked with Qt,I can’t say how much they differ in their actual usage.
I really like the fact that each window runs in its own thread,that’s something no other GUI toolkit does as far as I know,and it makes multithreading super simple.
The Layout Kit,if used properly,makes it easy to scale to different window sizes or screen resolutions (HiDPI).
Again,I don’t have any experience with Qt,so I can’t really compare that here.
BString has nothing to do with std::string,but you can easily convert a const char* to BString and a BString back to const char*.
I use it a lot and I quite like it for its simplicity. The rough edges, I think, are:
Unlike Qt, there is no signal/slot system. You have to manually route events (delivered as BMessage in the MessageReceived call) by a big switch/case determining which message was received, then extract the parameters by using FindInt32, FindString, etc on the message. Which also means no compile-time check on the name of the parameters (to the compiler they’re just strings in the parameters of the Find* functions). In modern C++ you’d probably be able to attach a lambda directly to the events and have it receive its parameters directly.
Each window runs in its own thread. It is good because it forces you to design your app with GUI in one thread and havy processing in another, and so the GUI is always responsive. It’s annoying because C++ makes it easier totake shortcuts and not actually do that, and then get into thread synchronization trouble.
The layout system works OK but is sometimes a bit quirky. I don’t know if there are better options out there.
Expect to do a lot of subclassing of standard controls if you want to do anything “unusual” with your UI. It’s great that creating custom controls is easy, and by using BControlLook you can make them look just as the native ones. It’s a bit annoying that sometimes the basic set of control is a bit limited and there is no other way than subclassing. You need to change a label color? Subclassing. You want to add an extra information element in the event message? Subclassing.
Layout builders provide almost-declarative GUI building. An actual declarative and compiled thing would be even better (thinking of XAML from Microsoft here), but this is as good as it gets without writing an extra compiler. Unfortunately it’s missing a few useful things, like the ability to declare a BBox or a BScrollView directly from a layout builder.
I would love to see more use of StartWatching/SendNotices instead of having to define specific messages and use SetTarget from the source side to direct the messages where needed. Basically StartWatching/SendNotices would allow multiple subscriber to an event, where SetTarget only allows one.