Commodity GUI library is coming [LWN.net]

Commodity GUI library is coming

Posted Nov 24, 2005 15:43 UTC (Thu) by khim (subscriber, #9252)
In reply to: Commodity GUI library is coming by macson_g
Parent article: Imendio AB announces the GTK+ on Mac OS X port project (GnomeDesktop)

No, it is not. As of Qt-4, it is splitted into smaller libraries, which allows you event to write console apps, using XML and networking facilities, but without linking all that GUI stuff.

This makes zero difference: it still can not play well with other libraries. I can use expat or libxml with Gtk+ for XML parsing, imlib or libmagick for image processing and so on. With Qt - I can use some features or ignore them. That's all. No choice. It's Qt or nothing. The same is true for MFC and other C++ libraries - I do not know why but different C++ libraries usually dislike to work in tandem unless they share common ancestry. It's possible to do, yes, but quite painfull. That's why we have KDE on Qt side, yet GNOME, XFCE, etc on the Gtk+ side.

P.S. It's like Linux: it can use modules, true but it in no way makes it microkernel.

(Log in to post comments)

Commodity GUI library is coming

Posted Nov 25, 2005 16:40 UTC (Fri) by ringerc (subscriber, #3071) [Link]

I personally also dislike the amount of functionality being bundled into Qt. I'm particularly uncomfortable with it's poor-but-integrated XML support, and the Arthur graphics framework in Qt4.

That said, you can still use expat or libxml2 with Qt. That's what a number of Qt apps do, because the Qt XML support isn't great. As for mixing C++ libraries, the biggest problem areas in my experience are "utility" classes - the things everybody needs, but the standard doesn't provide or does badly. Like a decent unicode string class (not std::wstring) or signalling mechanism differences (template based signals/slots, idl/precompiler based signals/slots, callbacks). Despite these issues, it doesn't seem that big a deal, and the Boost project helps a lot.

Qt4 lets you use the non-GUI parts of Qt without the GUI parts. I'll be interested to see how far that goes in the other direction - for example, it'll be interesting to see how comfortably Cairo can be used (portably) within Qt.