3.2 builds

Thus spake pgeerkens:

Ha! I have been runing everything in standalone mode to facilitiate
debugging. Let me see what happens when I run from the MM

Yeah, that might give you some tiling problems.


J.

Thus spake pgeerkens:

When I run from the Module Manager everything seems to work.

Good.

On a related topic: Have you looked at this implementation of a Zip-file
modifier?
javaworld.com/javaworld/jw-1 … olbox.html

Yes, I believe I looked at this one when I wrote ours. One reason why
I prefer ours is that it permits multiple simultaneous reads.


J.

Thus spake Brent Easton:

And brent-3.2@7825 adds a missing Help button to the Mass Piece Loader
(No help page written yet).

Merged to trunk@7835.

Someone need to make a list of the documentation we’re missing for 3.2.


J.

Thus spake soft-bug:

Just a feedback after launching the new 3.2 builds …

The font size used is __very small __… i have a good sight but it’s
now difficult to see small text, especially in editor mode.

The previous colored icons (editor mode) were blue/grey in the 3.1
series were neutral… now the yellow ones focus your attention on them
… and with these small texts (font size) is very difficult to find
something at a glance.

Could you post screenshots of both of these so we can get a clearer
idea of what you mean? (The text is not smaller for me.)


J.

Just ran the snv7833 Logged_8. So far, no problems. The mod properly saved itself.

Two questions:

  1. Are the images supposed to tile every time you open the module? It’s doing that here. I didn’t know if it was supposed to do that or if it’s supposed to be a one time thing unless the graphics change.

  2. Is there a math / expression engine it this one? If so, is there some documentation somewhere for using proper syntax for expressions?

Thus spake DrNostromo:

Just ran the snv7833 Logged_8. So far, no problems. The mod properly
saved itself.

Two questions:

  1. Are the images supposed to tile every time you open the module? It’s
    doing that here. I didn’t know if it was supposed to do that or if it’s
    supposed to be a one time thing unless the graphics change.

No, it’s supposed to happen the first time a module is opened, and
thereafter only when that module is modified.

  1. Is there a math / expression engine it this one? If so, is there some
    documentation somewhere for using proper syntax for expressions?

Yes, I believe so. There’s no documentation yet.


J.

The font size used is __very small __… i have a good sight but it’s
now difficult to see small text, especially in editor mode.

The previous colored icons (editor mode) were blue/grey in the 3.1
series were neutral… now the yellow ones focus your attention on them
… and with these small texts (font size) is very difficult to find
something at a glance.

I believe this is due to JRE 6 vs JRE 5 on windows, no changes where made to Vassal.

Hi Joel,
Not Yet, will look this week.
Brent.

*********** REPLY SEPARATOR ***********

On 25/09/2011 at 12:07 PM Joel Uckelman wrote:

Thus spake Brent Easton:

Joel,
There is a fix in branch brent-3.2@7824 for a bug that Tim found.
Brent.

Got it.

Have you had a chance to look into the two issues I emailed you about
on the 12th?


J.

Hi,

Here a screenshot about comparaison between 3.1.16 and the new 3.2 series.

I use :
26 Sep 2011 17:09:10.515 0 – Starting
26 Sep 2011 17:09:10.515 0 – OS Windows XP
26 Sep 2011 17:09:10.515 0 – Java version 1.6.0_24

The font size is smaller using the 3.2 on the same computer.

Regards,

Grégory

Here is grist for the mill gentlemen. I started encountering the Zip-file problem late yesterday, after I resolved my other issues. (No comments from the peanut gallery please.) Then today the first thing I did was to download com.jgoodies.looks.* and set it up by changing the body of initUIProperties to look like this:
// use native LookAndFeel
// NB: This must be after Mac-specific properties
try {
UIManager.setLookAndFeel(new com.jgoodies.looks.windows.WindowsLookAndFeel());
} catch (UnsupportedLookAndFeelException e) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (ClassNotFoundException e2) {
ErrorDialog.bug(e);
} catch (IllegalAccessException e2) {
ErrorDialog.bug(e);
} catch (InstantiationException e2) {
ErrorDialog.bug(e);
} catch (UnsupportedLookAndFeelException e2) {
ErrorDialog.bug(e);
}
}

Now I cannot reproduce the ZIP-file proble anymore, and have made several attempts, with small and non-existsent changes to two modules. It was not difficullt to reproduce the problem yesterday.

Weird. How is changing the look-and-feel affecting file locks, etc.

However, the jgoodies.com looks are much more pleasant to the eye that Java’s default, are free for non-commercial use, and a small programming effort would allow the user to select a look and feel from native-windows emulation, or several platform-independent LaF they call plastic. The two jar files are a shade over 400k.

This was all run on the most recent check-in of pgeerkens-3.2, which is all my changes on top of svn7831 on the trunk. ( I meant to get 7805, perhaps mistakenly, but the svn Console said it retrieved 7831 for me.)

one more thought: the jgoodies documentation claims to handle LaF changes more robustly than other LaF implementations; and the UIManager documentation recommends strongly calling
SwingUtilities.updateComponentTreeUI( Component c);
after a LaF change, which we do not do anywhere that I can see.

Thus spake pgeerkens:

This was all run on the most recent check-in of pgeerkens-3.2, which is
all my changes on top of svn7831 on the trunk. ( I meant to get 7805,
perhaps mistakenly, but the svn Console said it retrieved 7831 for me.)

This might explain why the ZIP archive problem went away for you—you
picked up some changes to that code over what you had with 7805.


J.

No, beccause I made the retrieval early yesterday, before I did anything else.

Thus spake pgeerkens:

one more thought: the jgoodies documentation claims to handle LaF
changes more robustly than other LaF implementations; and the UIManager
documentation recommends strongly calling
SwingUtilities.updateComponentTreeUI( Component c);

after a LaF change, which we do not do anywhere that I can see.

We set the LaF before any Components exist, which is why we don’t do
this.


J.

Thus spake pgeerkens:

Now I cannot reproduce the ZIP-file proble anymore, and have made
several attempts, with small and non-existsent changes to two modules.
It was not difficullt to reproduce the problem yesterday.

Is anyone able to reproduce the ZIP file problem with svn7835? Tim told
me that he can’t.


J.

svn7835.

Haven’t had any saving problems with this build. However, the main map does tile every time I open the mod …even if I open and just save it with no changes or very minor changes (but no changes to the graphics).

Otherwise, I haven’t noticed anything out of the ordinary and the tiling of the images every time it’s open is only a minor annoyance.

One thing I should point it is that the saving system will not remain focused on the mod directory. If I use “Save As”, rather than the browse box opening in the mod directory, it opens somewhere else and I always have to browse to the mod directory.

Thus spake DrNostromo:

svn7835.

Haven’t had any saving problems with this build. However, the main map
does tile every time I open the mod …even if I open and just save it
with no changes or very minor changes (but no changes to the graphics).

Can you be more specific about what it’s actually doing? Is it actually
taking as long on successive tries as the first time slicing happend?

Is this happening for anyone else?


J.

I just ran a test. It took 22 seconds to tile the map image. I made a change to the module version notes just to have something new to save and saved it. Reopening it took 19 seconds to tile the map image. If I close the module without saving anything, it does not tile the map image if I reopen it. It appears to only do it if any change is saved to the mod …even if the change has nothing to do with the graphics.