From: Gregory Seidman (gseidman_at_[hidden])
Date: 2001-04-02 10:52:43
David Allan Finch sez:
} nbecker_at_[hidden] wrote:
} > There are a number of good cross-platform guis. One is QT. Others
} > include FLTK and wxWindows. This subject is discussed frequently on
} > the python newsgroup.
} This is know. I was working on a platform independed library before
} some of these project even started (*1). Until 1997(ish) I would have
} suggested that wxWindows was the only one that was as good as Sticky
} but time has moved on. I have still yet to see an C++ API from any
} other the others apart from the old Fresco/Interview project that
} was in anyway a real C++ API.
I would argue that Qt is a C++ API that is genuinely C++. Unfortunately,
since they are trying to make money with it, they are bound by several
constraints which reduce the elegance of the API.
The two main constraints are backward compatibility and compiler
compatibility. If we were to take Qt's concepts (many of which are embedded
in other projects, such as sigc++) without its constraints, we could
develop a GUI library which does not depend on new language keywords
(signals, slots, emit), does not rely on generated code (the meta-object
compiler, or moc, which produces necessary source files), has compile-time
type checking for event propagation (rather than runtime as in Qt), does
not pollute the global namespace, and is everything that Qt could and would
be if it were starting from scratch with the assumption that every target
compiler is (nearly) spec-compliant and comes with a (nearly)
Making/keeping it cross-platform would require some lower-level API (GDK
comes to mind) which would be an abstraction of the capabilities available
on host platforms.
Qt is gradually trying to become a platform abstraction layer for all
things, including networking, threads/synchronization, GUI, I/O,
containers, etc. It is everything boost is not (commercial with restrictive
licensing, maintaining backward compatibility with itself, providing a
mostly working rather than elegant solution, no attempt to integrate with
STL, etc.). It is the "worse is better" of cross-platform C++ libraries.
This does not make it evil, mind you, but it makes it undesirable in the
eyes of the idealists (like me) who would prefer an elegant cross-platform
solution to "worse is better." A GUI library as part of Boost would be that
See http://www.jwz.org/doc/worse-is-better.html for a discussion of "worse
is better" and, afterward, consider Fred Brooks's words in The Mythical Man
Month: "Plan to throw one out. You will anyway." I claim that Qt is the
50%-80% solution that worse-is-better demands, but that it is the one to
throw out now that we have learned from it. Still, we'd better have
something good with which to replace it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk