Create account / Log in

Roadmap for VASSAL 4

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby mkiefte » March 27th, 2011, 8:11 pm

We would never be able to be completely platform neutral as the VASSAL
engine relies on a very wide list of libraries. What you describe would be
very limiting. Although it sounds like a good idea, we would only be able
to support the lowest common denominator with respect to both platform and
browser. That's great for small apps or very restricted ones, but I can see
us hitting brick walls a lot.

As for JavaScript itself, I see dynamic typing as a debugging nightmare.
We're actually trying to go in the opposite direction with better defensive
programming practises. In addition, we're currently looking at ways to
expand our capabilities not restrict them further (e.g., better graphics/3D
engine).

With respect to a C-based language, conversion from Java is relatively
straightforward excepting the UI. JavaScript has a lot of scoping issues
that make a straight translation very tricky.

I think the frontrunners are still the status quo (Java+Swing), Java+SWT,
Qt, or wxWidgets. They all have their problems, but having to rely on a
webbrowser (who might later decide that a feature we're using is actually an
annoyance) would create more problems in terms of support. Right now, we
support Windows, Mac, and Linux directly, but I can't imagine supporting
multiple web browsers and all the problems they introduce.

- M.

On 27 March 2011 12:43, generateui wrote:

>
> wxWidgets suggested by Michael looks like a good cross-platform
>> framework. It looks to me like higher level entry for developers
>> though, so I don't know if the developers could/would make that step.
>>
>
>
> First of all, wxWidgets is indeed cross-platform, but: it's still
> __platform dependant__, as currently every UI library is platform
> dependant. Namely: wxWidgets is dependant on the wxWidgets platform.
> This may sound a bit weird, but the current state of UI toolkits is that
> none of the toolkits/libraries implement a set of standardized
> interfaces. Truly platform independance would be achieved by having a
> set of interfaces for widgets/behaviour defined, and then implemented in
> the various libs/toolkits. Example: Say I make a login window. I *HAVE*
> to tie the code in the loginwindow to the UI lib. I cannot define an
> instance of interface Button. Instead, I have to define wxButton, or
> gwtButton, or javafxButton. If I'd be able to define a Code:
> private button Button;
>
> , i can have the instance of the button be polymorphic.
>
> Please don't consider JavaScript, it's great for scripting web pages,
>> but not for complex applications like this. JavaScript is interpreted
>> code, so you will get a huge performance hit from that alone. You'd
>> also need to use some other means for the "GUI" with JavaScript, so
>> you'd end up with browser dependent display code (DHTML/CSS) which
>> breaks every few months with updates. Despite the hype nothing serious
>> gets written like this. You have web games, but they are either flash
>> and/or very very simple. There is google apps, but although nicely
>> done, they do nothing as complex as VASSAL. HTML5 adds a lot of
>> features, but is far from final and there is inconsistent support for
>> it. Instead of JavaScript you could write an application in Flash/Flex
>> or Silverlight (ZunTzu 2 is planned to use Silverlight), but the step
>> to just making a desktop app with much more flexibility in what you
>> can do is small
>>
>
>
> GWT is a different beast. It can support Javascript, without ever
> working with javascript code directly. Modern browsers such as Chrome
> and Firefox actually compile javascript objects into anonymous classes,
> which are then consumed by the javascript engine. This results in very
> fast code execution. You can say the old IE <8 and FF <3 engines are
> indeed code interpreters, but newer engines lean towards JIT
> compilation, like Java or .NET. Especially for boardgames, performance
> is not really an issue. The above link to OpenSettlers demo uses 1MB of
> minified javascript code (!). That's a lot of interpretation. When
> loading locally from SSD, loadtime on a single core 1.5Ghz is below 1
> second. That's surely acceptable. And I even have not yet optimized the
> OpenSettlers code yet. There's a huge set of classes which are not
> really necessary, but are compiled by GWT nevertheless because I needed
> only a few classes.
>
> GWT only supports features which work in all major browsers. That's the
> reason SVG is not yet supported: it's implementation in the different
> browsers is not yet on par for every major browser. On the other hand,
> canvas _is_ supported by the major browsers, and as such supported by
> GWT 2.2.
>
> As I noted in my previous post, when there is a UI agnostic codebase, it
> doesnt matter if you want to use SWT of GWT of JavaFX or flash or
> whatever.
>
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: Roadmap for VASSAL 4

Postby generateui » March 27th, 2011, 10:29 pm

We would never be able to be completely platform neutral as the VASSAL
engine relies on a very wide list of libraries. What you describe would be
very limiting. Although it sounds like a good idea, we would only be able
to support the lowest common denominator with respect to both platform and
browser. That's great for small apps or very restricted ones, but I can see
us hitting brick walls a lot.


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: https://github.com/generateui/OpenSettl ... erSvg.java

If you explicitly do not support IE, you can have most cake and eat it too.

As for JavaScript itself, I see dynamic typing as a debugging nightmare.
We're actually trying to go in the opposite direction with better defensive
programming practises. In addition, we're currently looking at ways to
expand our capabilities not restrict them further (e.g., better graphics/3D
engine).


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

With respect to a C-based language, conversion from Java is relatively
straightforward excepting the UI. JavaScript has a lot of scoping issues
that make a straight translation very tricky.


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.

I think the frontrunners are still the status quo (Java+Swing), Java+SWT,
Qt, or wxWidgets. They all have their problems, but having to rely on a
webbrowser (who might later decide that a feature we're using is actually an
annoyance) would create more problems in terms of support. Right now, we
support Windows, Mac, and Linux directly, but I can't imagine supporting
multiple web browsers and all the problems they introduce.


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 :)
generateui
 
Posts: 4
Joined: March 27th, 2011, 2:23 pm

Re: Roadmap for VASSAL 4

Postby bdgza » March 28th, 2011, 10:28 am

generateui wrote: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 :)


* The game server is a single point of failure and will not scale.

Making all of VASSAL web-based, even if it runs mostly in client-side Javascript, will still add strain to an already strained server, and does not solve the single point of failure. If VASSAL must be redone as a web-based platform it must use technology which can run offline (when the server goes down). That leaves HTML5, Adobe AIR/Flex, MS Silverlight. HTML5 is completely unready. Adobe AIR runs on all currently supported platforms, but it basically a fancy Flash app, and I don't think it is suitable. MS Silverlight I think might be suitable someday, but it does not support Linux. The developer of ZunTzu is looking at Silverlight for ZunTzu 2, but I think it will be a tough nut to crack, and ZunTzu does a whole lot less than VASSAL. While there are some fancy web-apps out there, they all rely on their server and are all custom programmed to support one single game/task.

Bottom line is that I don't feel that all things considered there is any argument that makes web-based make more sense than a more suitable technology. You find the tools to fit the solution, not fit the solution around the tools. If you make it web-based, you force it through because you feel it must be web-based. Desktop applications provide a richer framework and more offline flexibility. Whats important is choosing one that works best on all three currently supported platforms, is easiest to expand to other platforms (iOS/Android/...), and is easiest for the developers to implement all the existing and future desired features (2D/3D graphics, modules and extensions, Python event scripting, ...).

I am not a developer either, so my contribution to this thread is all FYI too. I make desktop and web apps. Completely different field from VASSAL, but code is code :wink: .
bdgza
 
Posts: 316
Joined: February 26th, 2010, 10:51 am

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » March 28th, 2011, 12:14 pm

Thus spake Michael Kiefte:
>
> As for JavaScript itself, I see dynamic typing as a debugging nightmare.
> We're actually trying to go in the opposite direction with better defensive
> programming practises. In addition, we're currently looking at ways to
> expand our capabilities not restrict them further (e.g., better graphics/3D
> engine).

I was curious to see what could be done with JavaScript as it is now,
so I worked up two demos over the weekend, one using the HTML5 canvas,
and one using regular DHTML techniques. I've put the demos here for you
to try:

http://www.vassalengine.org/~uckelman/js-test.tar.bz2
http://www.vassalengine.org/~uckelman/js-test.zip

(Both archives have the same content, download the one you prefer.)

Once you've unpacked the archive, browse to launch.html, where you'll
find a link to each of the demos. In each demo, you should be able to
drag around the pieces. In the elements demo, dragging on the map pans
it.

I learned a few things by doing this:

1. The canvas demo is unusable for me. It turns out that this has
nothing to do with the huge map image---it's just as bad when there's
no map image. What does matter is the size of the canvas. It works well
for me at 1000x1000, but 8000x3000 is 24 times larger. I don't know how
the canvas is implemented in Firefox 3.6.16, but it seems that they're
not using algorithms which scale up well.

Also of note here is the fact that every canvas example I was able to
find on the web assumes that you'll have about 10 objects on your
canvas, so does collision detection by searching the whole object list
and testing each one for hits, and also repaints the whole canvas every
time something changes. If you do either of these, instead of using a
quadtree for collision detection and repainting only changed regions,
you can't even get a 1000x1000 canvas to work well with 100 objects on
it.

2. The elements demo works well for me. It's also 245 lines of code, 41
of which are just HTML. The reason it's so small is that all I had to do
was write event handlers for some mouse events. The browser is already
providing all of the collision detection, repainting, drag and drop,
and image loading. We have thousands of lines of code in VASSAL for doing
essentially the same thing.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8848
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby mkiefte » March 28th, 2011, 12:28 pm

Hi Joel,

Why did you comment out mapZoom(e)?

- M.

On 28 March 2011 09:13, Joel Uckelman wrote:

> Thus spake Michael Kiefte:
> >
> > As for JavaScript itself, I see dynamic typing as a debugging nightmare.
> > We're actually trying to go in the opposite direction with better
> defensive
> > programming practises. In addition, we're currently looking at ways to
> > expand our capabilities not restrict them further (e.g., better
> graphics/3D
> > engine).
>
> I was curious to see what could be done with JavaScript as it is now,
> so I worked up two demos over the weekend, one using the HTML5 canvas,
> and one using regular DHTML techniques. I've put the demos here for you
> to try:
>
> http://www.vassalengine.org/~uckelman/js-test.tar.bz2
> http://www.vassalengine.org/~uckelman/js-test.zip
>
> (Both archives have the same content, download the one you prefer.)
>
> Once you've unpacked the archive, browse to launch.html, where you'll
> find a link to each of the demos. In each demo, you should be able to
> drag around the pieces. In the elements demo, dragging on the map pans
> it.
>
> I learned a few things by doing this:
>
> 1. The canvas demo is unusable for me. It turns out that this has
> nothing to do with the huge map image---it's just as bad when there's
> no map image. What does matter is the size of the canvas. It works well
> for me at 1000x1000, but 8000x3000 is 24 times larger. I don't know how
> the canvas is implemented in Firefox 3.6.16, but it seems that they're
> not using algorithms which scale up well.
>
> Also of note here is the fact that every canvas example I was able to
> find on the web assumes that you'll have about 10 objects on your
> canvas, so does collision detection by searching the whole object list
> and testing each one for hits, and also repaints the whole canvas every
> time something changes. If you do either of these, instead of using a
> quadtree for collision detection and repainting only changed regions,
> you can't even get a 1000x1000 canvas to work well with 100 objects on
> it.
>
> 2. The elements demo works well for me. It's also 245 lines of code, 41
> of which are just HTML. The reason it's so small is that all I had to do
> was write event handlers for some mouse events. The browser is already
> providing all of the collision detection, repainting, drag and drop,
> and image loading. We have thousands of lines of code in VASSAL for doing
> essentially the same thing.
>
> --
> J.
>
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby uckelman » March 28th, 2011, 12:35 pm

Thus spake Michael Kiefte:
>
> Hi Joel,
>
> Why did you comment out mapZoom(e)?

Uncomment it and see. :)

I couldn't get it to work well enough using CSS scaling to be usable.

I had a third idea which I ran out of time to try, which is to do
everything inside of SVG, where you've got (presumably) better-
supported scaling and rotation. Since SVG is part of the DOM, it
wouldn't be much different from the code you're looking at.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8848
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby generateui » March 28th, 2011, 2:25 pm

* The game server is a single point of failure and will not scale.

Making all of VASSAL web-based, even if it runs mostly in client-side Javascript, will still add strain to an already strained server, and does not solve the single point of failure. If VASSAL must be redone as a web-based platform it must use technology which can run offline (when the server goes down). That leaves HTML5, Adobe AIR/Flex, MS Silverlight. HTML5 is completely unready. Adobe AIR runs on all currently supported platforms, but it basically a fancy Flash app, and I don't think it is suitable. MS Silverlight I think might be suitable someday, but it does not support Linux. The developer of ZunTzu is looking at Silverlight for ZunTzu 2, but I think it will be a tough nut to crack, and ZunTzu does a whole lot less than VASSAL. While there are some fancy web-apps out there, they all rely on their server and are all custom programmed to support one single game/task.

OpenSettlers does not rely on the webserver for hotseat games and botgames, it runs completely offline as an independent webapp. Off course, when you want to play against other players, a server is necessary.

A p2p server is also a problem for OpenSettlers, see the #1 issue: https://github.com/generateui/OpenSettl ... es#issue/1 . ipv6 might fix this partially (no more NAT portmapping horror), as homeserver platforms like Windows Home Server, Amahi and others might solve this problem too.

The thing about webservers is that afaik, they are built to scale. I don't have any realworld experience with high loads, but I can imagine it can be easy to add servers and balance the load. It's in the very DNA of webservers to do this. WebSockets might be a little different beast though, as it's relatively new and doesn't really fit in the 'fire and forget' nature of handling stateless requests.

Bottom line is that I don't feel that all things considered there is any argument that makes web-based make more sense than a more suitable technology. You find the tools to fit the solution, not fit the solution around the tools..


When I set out to write OpenSettlers, I had 2 requirements: 1. All variants of the game should be able to be implemented, 2: Users should have no barrier to play.

1 is not interesting in this topic, but 2 is. I came at GWT because a webapp offers the lowest barrier for users to participate. To play, the only thing needed is to enter an URI and click a button. No other platform could and can offer me this: Java applets require JVM install, flash requires the flash plugin, native apps require the traditional download-install-configure process.

The application server *must* be a 'native' application, as there is no way to accept connections in a web browser without plugins. That's why I plan to offer a central server to play games, but also a central metaserver to list gameservers.
generateui
 
Posts: 4
Joined: March 27th, 2011, 2:23 pm

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby mkiefte » March 29th, 2011, 6:22 pm

Some choice quotes regarding JavaScript on the Mozilla website that made me
cringe:

JavaScript is a small, lightweight language; it is not useful as a
> standalone language, but is designed for easy embedding in other products
> and applications, such as web browsers.
>
> JavaScript is a very free-form language compared to Java. You do not have
> to declare all variables, classes, and methods. You do not have to be
> concerned with whether methods are public, private, or protected, and you do
> not have to implement interfaces. Variables, parameters, and function return
> types are not explicitly typed.
>
> In expressions involving numeric and string values with the + operator,
> JavaScript converts numeric values to strings. For example, consider the
> following statements:
> 1x = "The answer is " + 42 // returns "The answer is 42"
> 2y = 42 + " is the answer" // returns "42 is the answer"
>
> In statements involving other operators, JavaScript does not convert
> numeric values to strings. For example:
> 1"37" - 7 // returns 30
> 2"37" + 7 // returns "377"
>
> Another unusual thing about variables in JavaScript is that you can refer
> to a variable declared later, without getting an exception.
>
> If an array is created using a literal in a top-level script, JavaScript
> interprets the array each time it evaluates the expression containing the
> array literal. In addition, a literal used in a function is created each
> time the function is called.
>


That's just the from first three pages. I'm actually going to learn
JavaScript anyway as I wouldn't mind using it for some lectures (I use
pdfLaTeX + Beamer and you can embed JavaScript in the resulting PDF). But
it kind of reminds me of MATLAB or perl -- not something that you'd want to
do a really big project in. (However, I have done really big projects in
MATLAB and they're a nightmare to debug).

- M.

On 28 March 2011 09:35, Joel Uckelman wrote:

> Thus spake Michael Kiefte:
> >
> > Hi Joel,
> >
> > Why did you comment out mapZoom(e)?
>
> Uncomment it and see. :)
>
> I couldn't get it to work well enough using CSS scaling to be usable.
>
> I had a third idea which I ran out of time to try, which is to do
> everything inside of SVG, where you've got (presumably) better-
> supported scaling and rotation. Since SVG is part of the DOM, it
> wouldn't be much different from the code you're looking at.
>
> --
> J.
>
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby Tim M » March 29th, 2011, 8:16 pm

uckelman wrote:I was curious to see what could be done with JavaScript as it is now,
so I worked up two demos over the weekend, one using the HTML5 canvas,
and one using regular DHTML techniques. I've put the demos here for you
to try:

http://www.vassalengine.org/~uckelman/js-test.tar.bz2
http://www.vassalengine.org/~uckelman/js-test.zip

(Both archives have the same content, download the one you prefer.)

Once you've unpacked the archive, browse to launch.html, where you'll
find a link to each of the demos. In each demo, you should be able to
drag around the pieces. In the elements demo, dragging on the map pans
it.

I learned a few things by doing this:

1. The canvas demo is unusable for me. It turns out that this has
nothing to do with the huge map image---it's just as bad when there's
no map image. What does matter is the size of the canvas. It works well
for me at 1000x1000, but 8000x3000 is 24 times larger. I don't know how
the canvas is implemented in Firefox 3.6.16, but it seems that they're
not using algorithms which scale up well.

Also of note here is the fact that every canvas example I was able to
find on the web assumes that you'll have about 10 objects on your
canvas, so does collision detection by searching the whole object list
and testing each one for hits, and also repaints the whole canvas every
time something changes. If you do either of these, instead of using a
quadtree for collision detection and repainting only changed regions,
you can't even get a 1000x1000 canvas to work well with 100 objects on
it.

2. The elements demo works well for me. It's also 245 lines of code, 41
of which are just HTML. The reason it's so small is that all I had to do
was write event handlers for some mouse events. The browser is already
providing all of the collision detection, repainting, drag and drop,
and image loading. We have thousands of lines of code in VASSAL for doing
essentially the same thing.

--
J.


So did I.

1. Running the Canvas test doesn't work - "This text is displayed if your browser does not support HTML5 Canvas." As one would expect if you are running IE8 or lower which will be at least 60% of the world :)

2. The element test does not work in IE8 either. I can only see the top left corner of whatever is being displayed "Axis Air Points". see no pieces, cannot scroll the map etc..

too many different browser issues to deal with going this approach
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1816
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby mkiefte » March 29th, 2011, 8:25 pm

I just had to post this bit. You're allowed to have an array of length 5 in
which the myArray[3] is invalid following delete myArray[3]; Object
properties seem unmanageable and methods are implemented rather poorly (you
have to assign them like variables). JavaScript seems fine for small
projects where you're the only developer, but for multi-developer projects,
it would be hard to coordinate. I really can't imagine working with this for
anything complicated.

From the docs:

At the implementation level, JavaScript's arrays actually store their
> elements as standard object properties, using the array index as the
> property name
>

Didn't sh used to work like this? I guess there's a reason why it's called
JavaScript.

- M.

On 29 March 2011 15:22, Michael Kiefte wrote:

> Some choice quotes regarding JavaScript on the Mozilla website that made me
> cringe:
>
> JavaScript is a small, lightweight language; it is not useful as a
>> standalone language, but is designed for easy embedding in other products
>> and applications, such as web browsers.
>>
>> JavaScript is a very free-form language compared to Java. You do not have
>> to declare all variables, classes, and methods. You do not have to be
>> concerned with whether methods are public, private, or protected, and you do
>> not have to implement interfaces. Variables, parameters, and function return
>> types are not explicitly typed.
>>
>> In expressions involving numeric and string values with the + operator,
>> JavaScript converts numeric values to strings. For example, consider the
>> following statements:
>> 1 x = "The answer is " + 42 // returns "The answer is 42"
>> 2y = 42 + " is the answer" // returns "42 is the answer"
>>
>> In statements involving other operators, JavaScript does not convert
>> numeric values to strings. For example:
>> 1 "37" - 7 // returns 30
>> 2"37" + 7 // returns "377"
>>
>> Another unusual thing about variables in JavaScript is that you can refer
>> to a variable declared later, without getting an exception.
>>
>> If an array is created using a literal in a top-level script, JavaScript
>> interprets the array each time it evaluates the expression containing the
>> array literal. In addition, a literal used in a function is created each
>> time the function is called.
>>
>
>
> That's just the from first three pages. I'm actually going to learn
> JavaScript anyway as I wouldn't mind using it for some lectures (I use
> pdfLaTeX + Beamer and you can embed JavaScript in the resulting PDF). But
> it kind of reminds me of MATLAB or perl -- not something that you'd want to
> do a really big project in. (However, I have done really big projects in
> MATLAB and they're a nightmare to debug).
>
> - M.
>
> On 28 March 2011 09:35, Joel Uckelman wrote:
>
>> Thus spake Michael Kiefte:
>> >
>> > Hi Joel,
>> >
>> > Why did you comment out mapZoom(e)?
>>
>> Uncomment it and see. :)
>>
>> I couldn't get it to work well enough using CSS scaling to be usable.
>>
>> I had a third idea which I ran out of time to try, which is to do
>> everything inside of SVG, where you've got (presumably) better-
>> supported scaling and rotation. Since SVG is part of the DOM, it
>> wouldn't be much different from the code you're looking at.
>>
>> --
>> J.
>>
>
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: [messages] [Developers] Re: [Developers] Re: Roadmap for

Postby mkiefte » March 29th, 2011, 8:26 pm

> 2. The element test does not work in IE8 either. I can only see the top
> left corner of whatever is being displayed "Axis Air Points". see no
> pieces, cannot scroll the map etc..
>
> too many different browser issues to deal with going this approach
>
>
I couldnt' scroll it either, but I assumed that was because the scroll bars
had to be implemented specifically. I did see the pieces, however.

- M.
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: [messages] [Developers] Re: [Developers] Re: Roadmap for

Postby uckelman » March 30th, 2011, 9:05 am

Thus spake Michael Kiefte:
>
> I couldnt' scroll it either, but I assumed that was because the scroll bars
> had to be implemented specifically. I did see the pieces, however.

Did you try to drag on the map? That's how scrolling was supposed to
work in the second demo. Were you able to drag the pieces?

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8848
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] [Developers] Re: [Developers] Re: Roadmap for

Postby mkiefte » March 30th, 2011, 9:09 am

I was able to drag the pieces, but not scroll the map. I did try clicking
on the map.

- M.

On 30 March 2011 06:04, Joel Uckelman wrote:

> Thus spake Michael Kiefte:
> >
> > I couldnt' scroll it either, but I assumed that was because the scroll
> bars
> > had to be implemented specifically. I did see the pieces, however.
>
> Did you try to drag on the map? That's how scrolling was supposed to
> work in the second demo. Were you able to drag the pieces?
>
> --
> J.
>
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: [messages] [Developers] Re: [Developers] Re: Roadmap for

Postby uckelman » March 30th, 2011, 9:10 am

Thus spake Michael Kiefte:
>
> I was able to drag the pieces, but not scroll the map. I did try clicking
> on the map.
>

Clicking on the map, or dragging? Just clicking on the map won't do
anything.

In what browser?

--
J.
User avatar
uckelman
Site Admin
 
Posts: 8848
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] [Developers] Re: Roadmap for VASSAL 4

Postby mkiefte » March 30th, 2011, 9:14 am

I finished reading the Mozilla documentation on JavaScript, and inheritance
is a nightmare. Since there are not classes, inheritance is based on a
prototype instantiation. The syntax for inheritance is a gigantic kludge and
there appear to be several ways of doing it--none of which are necessarily
intuitive. I have a sudden urge to do everything in assembler. There are a
few other quirks that will make it bug prone -- some of which I posted
above. I was against JavaScript before I started investigating it and now
I'm actually much more firm in my opposition. It's a bad language.

- M.

On 29 March 2011 17:25, Michael Kiefte wrote:

> I just had to post this bit. You're allowed to have an array of length 5
> in which the myArray[3] is invalid following delete myArray[3]; Object
> properties seem unmanageable and methods are implemented rather poorly (you
> have to assign them like variables). JavaScript seems fine for small
> projects where you're the only developer, but for multi-developer projects,
> it would be hard to coordinate. I really can't imagine working with this for
> anything complicated.
>
> From the docs:
>
> At the implementation level, JavaScript's arrays actually store their
>> elements as standard object properties, using the array index as the
>> property name
>>
>
> Didn't sh used to work like this? I guess there's a reason why it's called
> JavaScript.
>
> - M.
>
> On 29 March 2011 15:22, Michael Kiefte wrote:
>
>> Some choice quotes regarding JavaScript on the Mozilla website that made
>> me cringe:
>>
>> JavaScript is a small, lightweight language; it is not useful as a
>>> standalone language, but is designed for easy embedding in other products
>>> and applications, such as web browsers.
>>>
>>> JavaScript is a very free-form language compared to Java. You do not have
>>> to declare all variables, classes, and methods. You do not have to be
>>> concerned with whether methods are public, private, or protected, and you do
>>> not have to implement interfaces. Variables, parameters, and function return
>>> types are not explicitly typed.
>>>
>>> In expressions involving numeric and string values with the + operator,
>>> JavaScript converts numeric values to strings. For example, consider the
>>> following statements:
>>> 1 x = "The answer is " + 42 // returns "The answer is 42"
>>> 2y = 42 + " is the answer" // returns "42 is the answer"
>>>
>>> In statements involving other operators, JavaScript does not convert
>>> numeric values to strings. For example:
>>> 1 "37" - 7 // returns 30
>>> 2"37" + 7 // returns "377"
>>>
>>> Another unusual thing about variables in JavaScript is that you can refer
>>> to a variable declared later, without getting an exception.
>>>
>>> If an array is created using a literal in a top-level script, JavaScript
>>> interprets the array each time it evaluates the expression containing the
>>> array literal. In addition, a literal used in a function is created each
>>> time the function is called.
>>>
>>
>>
>> That's just the from first three pages. I'm actually going to learn
>> JavaScript anyway as I wouldn't mind using it for some lectures (I use
>> pdfLaTeX + Beamer and you can embed JavaScript in the resulting PDF). But
>> it kind of reminds me of MATLAB or perl -- not something that you'd want to
>> do a really big project in. (However, I have done really big projects in
>> MATLAB and they're a nightmare to debug).
>>
>> - M.
>>
>> On 28 March 2011 09:35, Joel Uckelman wrote:
>>
>>> Thus spake Michael Kiefte:
>>> >
>>> > Hi Joel,
>>> >
>>> > Why did you comment out mapZoom(e)?
>>>
>>> Uncomment it and see. :)
>>>
>>> I couldn't get it to work well enough using CSS scaling to be usable.
>>>
>>> I had a third idea which I ran out of time to try, which is to do
>>> everything inside of SVG, where you've got (presumably) better-
>>> supported scaling and rotation. Since SVG is part of the DOM, it
>>> wouldn't be much different from the code you're looking at.
>>>
>>> --
>>> J.
>>>
>>
>
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest