[messages] [Developers] Re: Roadmap for VASSAL 4
bo.leer.andersen3 at gmail.com
Thu Jul 21 09:48:44 MST 2011
> I used Qt some years ago. I found it to be quite irritating that it
> had poor integration with the Standard Template Library, and the
> to which it was generating code using its special preprocessor made
> some problems a nightmare to debug. One of the things which people
> to as an advantage of Qt---namely, that it is a giant, all-encompasing
> framework providing everything you might need---is also touted as an
> advantage of Java, and it one of the reasons why I don't ever want to
> use Java again if I can avoid it. Using a monolithic library means
> it's harder to swap out parts which are unsuitable or broken, and such
> libraries will tend to worm their way into every part of your design.
> want to keep our dependencies on third-party libraries as confined as
> possible, so that we're free to replace them as needed.
I understand your concern, but most if not all cross-platform GUI
toolkits are all-encompasing. Primarily due to the sheer complexity of
constructing a cross-platform C++ GUI toolkit. Other cross-platform GUI
toolkits, like for example wxWidgets and Juce are also all-encompasing,
as in so far as they use their own container types (like QString, QList
in Qt). STL is not used in any GUI toolkit I have been able to find. The
reason cross-platform GUI toolkits don't use STL, I think, is that STL
is not available on all platforms, and that STL is heavily dependent on
templates, witch not all compilers handle adequately.
Qt has some support for STL in its container classes, allowing for
relatively easy bridging between the container types. Using Boost with
Qt shouldn't be a problem, if this is preferred to Qt utility libraries
(networking, threading, file handling and so forth).
Decoupling the toolkit libraries from the application model /
architecture can be ensured to some degree by a proper design using a
layer of indirection between the application model and the GUI toolkit
libraries, though a complete decoupling (toolkit having no effect on the
design of the application architecture), would be hard to achieve. But
this would be true for any GUI toolkit.
So short of developing your own cross-platform GUI toolkit (witch of
cource isn't feasible :P), you'll always end up with some dependcies to
the GUI toolkit. Changing the GUI toolkit once implemented, would be a
huge task no matter witch toolkit is choosen. So choosing a toolkit with
proper cross-platform support, proper documentation, proper design, good
rendering performance, vibrant community and so forth, is in my eyes key
But I can gather from the previous post, that you at the current stage
primarily are looking at the model design and module file format, and
haven't really decided on a GUI toolkit yet. I just wanted to make sure
that you where aware of the Qt toolkit.
By the way, I love your C++ test demo. Clearly out performs the current
Java rendering performance :D
Read this topic online here:
More information about the messages