From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-08-24 18:50:24
> > It seems that what you're at is a full-blown standalone C++ GUI library.
> > Maybe, it's good goal, but there a lot of toolkits already. I think it's
> > likely that just a new library will find a lot of users. If somebody has
> > or GTK application, he won't rewrite it just because your library is
> > or better in some other way.
> My experience, mostly from reading the documentation, is that there are no
> GOOD cross-platform C++ GUI libraries out there.
> The likes of WxWindows and GTKMM (the C++ GTK for those who haven't come
> across if before) suffer, IMO from lack of modern C++ techniques (not even
> namespaces in WxWindows' case), and unnecessary reinvention of the wheel for
> things like strings, and neither are exception safe. Which, in my mind,
> doesn't really make them C++ libraries.
There is no way to say this other than...
"Have you used std::string vs any GUI library version of string?"
std::string is lame. --> that is why most GUI libraries re-invent their own string class - to overcome the shortcomings of std::string.
Also, define what "exception safe" means... in the context of: you left-double-click on an item in a treelist. What do you do to handle this event?
Normally your event handler generates:
1. LeftMouseDown event
2. LeftMouseUp event
3. LeftMouseDown + LeftMouseUp + MouseMove < 4 pixels, is detected. This generates a LeftClick
4. Repeat steps 1-3
5 LeftClick + LeftClick + MouseMove < 4 pixels, is detected. This generates a LeftDoubleClick
Interposed with each of these events, is the possibility for the application to handle the event by doing some work, eg highlight the clicked treeitem, by handling the LeftClick event. By the very fact of highlighting, you have now modified some state within the treelist widget. Since you have modified state, it becomes extremely hard to rollback your selection (to the previous selection) if an exception is thrown in your LeftDoubleClick handler.
So the question should not be "is a GUI library exception safe" but rather "can you throw exceptions 'through' the GUI library and expect the semantics of the exception to be valid".
>From my experience, most modern GUI libraries allow exceptions to be thrown through them, although they generally dont throw exceptions themselves, as this tends to break the event handling mechanisms.
> Also, they try and do more than be a GUI library, for example by supporting
> threading and database access.
... why wouldn't a GUI library contain a database browse widget?
... are you suggesting that a worker thread would never want to update some onscreen value?
> I can't comment on Qt's exception safety, but I'm put off that because it's
> no longer free to Windows users. I believe it also does some wheel
> reinvention and database and threading stuff. I didn't like the extra
> compile stage for the messaging mechanism either.
> Anyway, so what's my point? My point is that I believe the C++ community is
> crying out for a good real C++ solution.
Good C++ solutions exist. Its the definition of "good" that needs to be defined.
> GUI use often does tie people into a particular library.
How could it not? Each library implements a set of API's... thats the reason for wanting a cross-platform library.
> Not many people
> seem to separate their backend logic from the GUI code, so it would be
> difficult for a lot of people to _change_. However, what about people like
> me who often start new projects or who do separate (I believe) correctly.
Thats because it is extremenly hard work to seperate event handling, from executing a backend task - I'd say its next to impossible - how would you know what backend work you want to execute without putting the current backend state-logic within the context of your event handlers?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk