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.
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: 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.
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.
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).
On 28 March 2011 09:35, Joel Uckelman uckelman@nomic.net 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.
So did I.
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
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 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.
On 29 March 2011 15:22, Michael Kiefte mkiefte@dal.ca 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 uckelman@nomic.net 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.
- 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.
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.
I was able to drag the pieces, but not scroll the map. I did try clicking
on the map.
On 30 March 2011 06:04, Joel Uckelman uckelman@nomic.net 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.
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.
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.
On 29 March 2011 17:25, Michael Kiefte mkiefte@dal.ca 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 nameDidn’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 mkiefte@dal.ca 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 uckelman@nomic.net 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.
No I tried that. I was on Firefox (not the latest I think) on a MacBook Pro
running Linux. The MagicMouse is a little wierd under Linux, but it works
for everything else (except there’s no middle button and there is no virtual
scroll wheel). I didn’t try it on anything else.
On 30 March 2011 06:10, Joel Uckelman uckelman@nomic.net wrote:
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?
Thus spake Michael Kiefte:
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.
I’m not in favor of it either. Making those demos was an interesting
exercise, but I don’t see that JavaScript is suitable for a large
project. The fact that it’s dynamically, weakly typed will make testing
hard, and the lack of block scoping rules strikes me as error-prone. I
think it would be interesting to have a web-based client, but I think it
shouldn’t be the primary client. Maybe by the time we’re ready to
develop something web-based, browser support will be in a better state
(e.g., WebGL will be available).
I think the next thing I’m going to look into is making the same demo
in Python, using the OpenGL bindings.
–
J.
I thought you hated Python. I’ve never used it but I know it has a lot of fans.
The more I think about it though, the more I like Java. It’s pretty good. Although if we want a better looking UI, we may want to consider SWT instead of Swing.
Java is a good language to attract new developers. And now with Gosling at Google, it may survive the next decade.
On 2011-03-30, at 7:28 AM, Joel Uckelman uckelman@nomic.net wrote:
Thus spake Michael Kiefte:
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.I’m not in favor of it either. Making those demos was an interesting
exercise, but I don’t see that JavaScript is suitable for a large
project. The fact that it’s dynamically, weakly typed will make testing
hard, and the lack of block scoping rules strikes me as error-prone. I
think it would be interesting to have a web-based client, but I think it
shouldn’t be the primary client. Maybe by the time we’re ready to
develop something web-based, browser support will be in a better state
(e.g., WebGL will be available).I think the next thing I’m going to look into is making the same demo
in Python, using the OpenGL bindings.–
J.
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
Thus spake Michael Kiefte:
I thought you hated Python. I’ve never used it but I know it has a lot of fa
ns.
What I dislike about it is the whitespace rules. Nonetheless, a lot of
people seem to like it, and there are tons of good libraries. So I want
to investigate it to see if it would be appropriate.
The more I think about it though, the more I like Java. It’s pretty good. Al
though if we want a better looking UI, we may want to consider SWT instead of
Swing.Java is a good language to attract new developers. And now with Gosling at Go
ogle, it may survive the next decade.
The things which worry me the most about Java are:
We could avoid the first one by not using Swing. We could avoid the
second by using some third-party image-loading library, but I haven’t
found a very complete one in the little looking I did. In both cases,
we can’t do much to get the problems fixed—some of the image loading
bugs I’ve encountered are years old. If we were using some library not
part of the JDK, then at least we could patch the thing ourselves and
ship that.
The heap sizing issue is just incredibly annoying, both in terms of
support and the code we have which tries to work around it, and I don’t
see any solution for this on the horizon.
It’s not clear to me what the long-term situation of Java on the Mac is
—we might suddenly find that there is no longer a working JVM there.
Using it also prevents us from having something which could work on iOS.
Because we’re relying on the JVM, we end up with all kinds of weird
launching failure problems on Windows, which wouldn’t happen if VASSAL
were run from its own binary. I’m also not convinced that Google’s
support of Java will help with Java on the desktop—it might mean that
we end up with good Java support on Android phones and tablets, but not
on the desktop.
So, I’m not ruling it out. But it seems saddled with a lot of problems.
–
J.
- Swing bugs
You could substitute those with SWT bugs!
- Image loading bugs
I doubt that would improve with SWT. If anything, SWT is harder to work
with, but it looks nicer.
- Jumping through hoops due to heap sizing
That problem will never go away.
- Mac support
Which is declining apparently.
- Hard-to-troubleshoot launching problems
I haven’t been paying much attention to that.
- Whether the desktop ecosystem is dying
In Java specifically or with desktops in general? Desktops will be around
for quite a long time and there is even some evidence they have gained on
game consoles. But Java may be dying on the desktop.
In other news wxWidgets posted a new release yesterday, so at least they’re
active. Working with wxWidgets is not without some pain, but at least we
can contribute fixes. Qt is still out there, but there’s a lot of news
about whether Nokia will even exist in 5 years given some controversial
decisions they’ve made. Although KDE may save it, KDE will likely not care
about development on new platforms.
wxWidgets doesn’t really have a good record of expanding to new platforms
either. Ironically, what they really need is some corporate sponsorship.
Of course the main advantages of either Qt or wxWidgets is the vast number
of libraries available for C and C++. Oh and I forgot about GTK which is
very hard to use. Has anyone compiled anything with GTK for Windows besides
GIMP?
I’m not sure who to root for.
Of course the main advantages of either Qt or wxWidgets is the vast number
of libraries available for C and C++. Oh and I forgot about GTK which is
very hard to use. Has anyone compiled anything with GTK for Windows besides
GIMP?
Evidently, someone has:
Not a lot of diversity. I still have a GTK book lying around somewhere.
Never did anything with it. Lot of hoops to jump through to do OOP in C.
Presumably the latter. The death of the PC is always over exaggerated
etforecasts.com/products/ES_pcww1203.htm
The sheer size of the PC market indicates otherwise.
Thus spake Michael Kiefte:
- Swing bugs
You could substitute those with SWT bugs!
I can’t imagine the SWT devs being slower to fix things than Sun/Oracle
have been.
- Image loading bugs
I doubt that would improve with SWT. If anything, SWT is harder to work
with, but it looks nicer.
Does SWT use it’s own image loader? I would have thought it would have
used BufferedImages and relied on ImageIO for image loading.
- Whether the desktop ecosystem is dying
In Java specifically or with desktops in general? Desktops will be around
for quite a long time and there is even some evidence they have gained on
game consoles. But Java may be dying on the desktop.
With respect to Java in particular. I don’t expect that the desktop will
go away. I can’t imagine coding on my phone.
Of course the main advantages of either Qt or wxWidgets is the vast number
of libraries available for C and C++. Oh and I forgot about GTK which is
very hard to use. Has anyone compiled anything with GTK for Windows besides
GIMP?
I seem to recall having done that once. I actually kind of like GTK myself.
–
J.
I seem to recall having done that once. I actually kind of like GTK myself.
I thought it was a good idea because I hate C++, but it really is hard to
use. I’m also not keen on function names with 14 underscore characters.
You can use Glade, but VASSAL uses run-time dialog creation (which, in
retrospect, might be hard to do in Qt).
Thus spake Michael Kiefte:
I thought it was a good idea because I hate C++, but it really is hard to
use. I’m also not keen on function names with 14 underscore characters.
You can use Glade, but VASSAL uses run-time dialog creation (which, in
retrospect, might be hard to do in Qt).
I was thinking that we should mandate that all private functions start
with 14 underscores: ______________move(int x, int y).
Seriously, though, the runtime-dialog creation is something we need to
think about. I thought there were systems in C++ which could create
dialogs from text specifications at runtime.
–
J.