[messages] [Developers] Roadmap for VASSAL 4

Joel Uckelman uckelman at nomic.net
Tue Mar 22 07:09:58 MST 2011


Thus spake Michael Kiefte:
> --===============7708843094333209693==
> Content-Type: multipart/alternative; boundary=0016364ed8dccdd72e049f11cb57
> 
> --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
> boots).

I share this worry. It has disadvantages similar to Java being owned by
Oracle.
 
> 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
> not sure about JavaScript as doesn't really seem that powerful. And I'm not
> really keen on anything that's interpreted (yes, technically, Java is
> interpreted, sort of, I know, but still).

According to a friend of mine, JavaScript is almost as fast as native
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.

There's some interesting stuff on the horizon w/r/t JavaScript, such as
WebGL.

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
which handle

  * 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
decent ones.

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
Linux.

-- 
J.


More information about the messages mailing list