As Vassal is written in Java, Vassal ties itself to the Java platform, which depends on… the JVM (Java platform). I’m very curious about the limitations you see towards the things I describe. As I see GWT as a few things, I also see GWT as a GUI library. From that perspective, It would not be limiting, but just another option to perform the GUI implementation with.
To build further on the Robber code example links I posted: I have an SvgRobber, but as well I can make a CanvasRobber or Canvas3DRobber. All XxxRobber classes implement RobberVisual and subscribe to the MovedEvent to change their [x,y] location. The Robber behaviour and data is seperated into a Robber class, and abstractly defined in RobberVisual interface and implemented in SvgRobber class (or the future CanvasRobber class).
See for RobberSvg: github.com/generateui/OpenSettl … erSvg.java
If you explicitly do not support IE, you can have most cake and eat it too.
Exactly. That’s why GWT worked out for OpenSettlers so well. No dynamic typing, good IDE support, and improved capabilities for the UI (such as canvas, canvas3d (WebGL), html and SVG).
I’m not sure if you’re replying on me, or a previous post. I only talked about C with Pioneers as example, so I assume you’re not replying with above quote to my post.
The point of Uckelman is to decouple classes currently tightly coupled to SWT from the UI toolkit, seperate UI classes from other classes. When that’s done, it does not really matter what UI toolkit one uses. OpenSettlers uses currently 2: an external SVG library, and the GWT widgets. As the architecture of OpenSettlers explicitly supports this using interfaces (loosely coupled design), I can make widgets in SWT, GWT, JavaFX, Canvas, SVG, whatever I like. The question indeed would be what UI library Vassal would support officially, which I should not answer as I am not part of Vassal.
Your last sentence make me believe that what GWT does is not fully understood. Applications written with GWT are entirely written and debugged in java and your favorite IDE. GWT contains a compiler which translates Java to Javascript, so a user can run the application in the browser. GWT makes different permutations for each browser, to ensure the small (and sometimes big in the case of IE) differences are taken care of. That’s something GWT does by default, nothing which the programmer needs to do. I have actually not written a single sentence of javascript, though OpenSettlers still runs 100% natively (no flash/java applet, 100% html/javascript/css) in the browser. By using GWT, I have a single codebase, and I can support any browser, device (as long as it has a modern browser, like Android and IOS devices) and resolution (abstracted UI in OpenSettlers takes care of this). I don’t have to worry about OSes, since the browser itself abstracts the OS. Apart from the SVG element (GWT 2.2, which supports canvas, removes the need for SVG), I have not yet found any crossbrowser bugs. Crossbrowser support is handled by GWT, not by the programmer coding against GWT.
I am no contributor for Vassal, so the things I share on this forum are just FYI. It’s just my experience devving on a codebase in many aspects similar to Vassal’s. I don’t own Google shares, I’m just a techdude sharing learned lessons