Create account / Log in

Roadmap for VASSAL 4

Discussion area for the development team.

Moderators: uckelman, Tim M

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

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

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.

- M.

On 30 March 2011 06:10, Joel Uckelman 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?
>
>
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 30th, 2011, 10:28 am

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

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

Postby mkiefte » March 30th, 2011, 11:21 am

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.

- M.

On 2011-03-30, at 7:28 AM, Joel Uckelman 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
> http://www.vassalengine.org/mailman/listinfo/messages
>
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 30th, 2011, 12:36 pm

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:

* Swing bugs
* Image loading bugs
* Jumping through hoops due to heap sizing
* Mac support
* Hard-to-troubleshoot launching problems
* Whether the desktop ecosystem is dying

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

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

Postby mkiefte » March 30th, 2011, 1:12 pm

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

- M.
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 mkiefte » March 30th, 2011, 1:15 pm

> 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:

http://www.gtk.org/screenshots.html

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.

- M.
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 30th, 2011, 1:50 pm

mkiefte wrote:>

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



Presumably the latter. The death of the PC is always over exaggerated

http://www.etforecasts.com/products/ES_pcww1203.htm

The sheer size of the PC market indicates otherwise.
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: 1817
Joined: December 8th, 2007, 12:22 pm
Location: Earth

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

Postby uckelman » March 30th, 2011, 1:53 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

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

Postby mkiefte » March 30th, 2011, 2:12 pm

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

- M
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 30th, 2011, 3:19 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

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

Postby mkiefte » March 30th, 2011, 3:58 pm

You can do that in wxWidgets I believe.

See:
http://docs.wxwidgets.org/stable/wx_xrc ... rcoverview

That's how the GUI editors for wxWidgets work. Never done it though.

Not sure if there is an equivalent in Qt -- I have a lot less experience
with it (like -- almost none).

- M.

On 30 March 2011 12:19, Joel Uckelman wrote:

> 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.
>
>
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 tar » March 30th, 2011, 4:00 pm

On Mar 30, 2011, at 5:36 AM, Joel Uckelman wrote:

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

From what I see (and presumably you as well, since you're on the
Apple Java developer mailing list) is that Oracle will be taking over
the task of delivering Java VMs for the Mac as well as their current
Windows and Linux/Unix versions. In some ways that is likely to be an
improvement over the current situation where Apple's release is often
a bit behind the Oracle releases.
User avatar
tar
 
Posts: 776
Joined: January 2nd, 2008, 6:53 pm
Location: Los Angeles area

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

Postby uckelman » March 30th, 2011, 4:03 pm

Thus spake Thomas Russ:
>
> From what I see (and presumably you as well, since you're on the
> Apple Java developer mailing list) is that Oracle will be taking over
> the task of delivering Java VMs for the Mac as well as their current
> Windows and Linux/Unix versions. In some ways that is likely to be an
> improvement over the current situation where Apple's release is often
> a bit behind the Oracle releases.
>

It might improve the lag situation. It might mean that nobody is stuck
on Java 1.5 anymore, either, which would be great. I'm not holding my
breath for Oracle to fix the long standing non-Mac-specific bugs that I
was complaining about, though. It might happen that they get fixed in
OpenJDK---I do see a fair bit of activity there---but that's of no help
to us until everybody on every platform we support can run it.

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

Re: Roadmap for VASSAL 4

Postby uckelman » April 18th, 2011, 9:11 pm

I spent the week before last creating a demo program in Python, to see what is possible there. You can see the result here:

http://www.vassalengine.org/~uckelman/pytest.tar.bz2
http://www.vassalengine.org/~uckelman/p ... indows.zip

To run the non-Windows version, you need Python, pygame, PyOpenGL, and numpy installed. For the Windows version, everything is supposed to be included, but I can't test it because OpenGL doesn't work on the Windows XP virtual machine where I built the package. In either case, the way to run the demo is from the command line.

For Windows: threedee.exe map.png

Everywhere else: threedee.py map.png

I was surprised by how little code it took to get this working. It's only 601 lines, including a bunch of dead code I could remove. Please give this a try, and let me know how it works for you.

On a related note, were we to use Python, how many of us already know it? Are willing to learn it? Similarly, were we to use C++, how many of us already know it? Are willing to learn it?
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

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

Postby mkiefte » April 18th, 2011, 10:44 pm

On 18 April 2011 18:11, uckelman wrote:

> I was surprised by how little code it took to get this working. It's
> only 601 lines, including a bunch of dead code I could remove. Please
> give this a try, and let me know how it works for you.
>

Works for me. I have some questions though. You appear to be using
pygame. Does that limit you in terms of what you can do with OpenGL? For
example, it's obvious you can do textures (or whatever we're supposed to
call them now), but can you actually do 3D rendering from pygame? My
impression was that pygame is limited to 2D games.


> On a related note, were we to use Python, how many of us already know
> it?


Not me.


> Are willing to learn it?


Can't be worse than perl, right?


> Similarly, were we to use C++, how many of
> us already know it?


I do, unfortunately. Can't be worse than perl, right?


> Are willing to learn it?
>

As long as we keep it to the subset that is compatible with ANSI C, sure.

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