[messages] [Developers] Roadmap for VASSAL 4
uckelman at nomic.net
Tue Mar 22 07:09:58 MST 2011
Thus spake Michael Kiefte:
> Content-Type: multipart/alternative; boundary=0016364ed8dccdd72e049f11cb57
> Content-Type: text/plain; charset=ISO-8859-1
> I am entirely suspicious of Qt. Qt has been in a license quagmire from day
> one. I agree it's a fine toolkit, but do you even know who owns Qt right
> now? Even if you do, the answer might change shortly (the answer is Nokia
> who, last I heard, will likely be laying off all of their Qt people in
> favour of Windows--soon they will be back to only selling tyres and rubber
I share this worry. It has disadvantages similar to Java being owned by
> Don't get me wrong; I really, really, really want to like Qt. I even
> purchased a cross-platform license years ago before concluding that it was
> going to be a huge hassle in terms of licensing. Even though it's currently
> LGPL, it could be dead within a year.
I used Qt extensively for the board game program I was developing before
becoming a VASSAL developer. I grew to hate it, because it required all
sorts of weird build tools and macros, and was awful to debug as a result.
> So far, I hear wxWidgets, Qt, and Java (either Swing or JTK). All are fine
> platforms. The real issue is ownership and long-term viability. I'm really
> really keen on anything that's interpreted (yes, technically, Java is
> interpreted, sort of, I know, but still).
these days. I don't much care about interpreted vs. compiled for things
which aren't speed-critical; what I care more about is static typing, as
non-statically typed languages are harder to write meaningful tests for.
I think the important aspects of language and library choice are:
1. We need a language (or languages, if the frontend and backend aren't
necessarily in the same language) for which there are good libraries
* smooth image scaling and rotation
* P2P networking
These are the two things we can't do ourselves, the former because it
needs to be done by something hardware-accellerated, and the latter
because we're just not qualified to write a P2P library ourselves. Other
things for which we rely on libraries, such as image and XML loading,
aren't such an issue, because basically any language we use will have
2. We need a language and libraries which have a developer community
that isn't disappearing, and looks like it will still be viable some
years from now.
3. We need a GUI toolkit which works on Macs, Windows, and Linux, and
doesn't look awful.
4. It would be helpful if all of these things were produced by groups
not owned by any company.
5. It would be helpful if one could produce builds for all systems from
More information about the messages