Create account / Log in

Text labels in 3.2.0: bug or feature?

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: Text labels in 3.2.0: bug or feature?

Postby uckelman » October 8th, 2012, 5:56 pm

Thus spake barbanera:
>
> Joel, maybe this discussion about the "centering" bug should be moved
> now to the relative thread (see link in a previous post), at any rate I
> can confirm that I noticed this bug back in January this year, when
> strictly using Vassal 3.1.18. Moreover, I have just checked and it's
> still there in 3.2.0 build 8249.
>
> I created a test module to demonstrate it:
> text_label_centering_bug.vmod
> (instructions in the module when you run it).
>
> While I was at it I added the demonstration of some lurking issue with
> the "line feed" bug/thing (to which this thread was originally
> dedicated): having a text label only printing something like $FOO$ gives
> a new line with the content of $FOO$ - _even when empty_ - but only if
> not followed in the trait order by another text label with some actual
> static text. Otherwise, it will overlap the following text label in the
> trait order (which is actually printed first). Is this as expected..?
> Note that if the following text label does not have static text, but
> rather just something like $BAR$, both $FOO$ and $BAR$ will appear on
> their own lines (no overlap).

Is this still a problem in 3.2.0-svn8397?

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

Re: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 9th, 2012, 3:51 pm

YES, still a problem.

If any work at all was done on text labels since this report, then it didn't address these problems at all.
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

Re: Text labels in 3.2.0: bug or feature?

Postby uckelman » October 9th, 2012, 4:19 pm

Thus spake barbanera:
> YES, still a problem.
>
> If any work at all was done on text labels since this report, then it
> didn't address these problems at all.
>

Please put this into the bug tracker, then.

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

Re: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 9th, 2012, 8:46 pm

I searched the tracker and it looks like there is a bit of a mess regarding the text label situation. Therefore, I am unsure if/what to add to the tracker as a genuine new bug.

I have come up with the following (biased) list of open issues;

1) There is a "centering" bug, dating back to 3.1.x and discussed in various threads and finally reported as bug 4322 by David Robert, who even looked at the code, found it was a caching issue and proposed a fix. Check his test module or my test module here. Still open.

2) There is a "unselectable" bug with text labels on pieces which have no imaged defined, reported as bug 4600, but the jury is still out on this (bug or no bug? feature request?).

3) There is a "overlapping" bug with multiple text labels, which come up with early 3.2.0 builds. Brent looked at this and presumably (see below) fixed it from build 8228. However, he did add it as bug 4632 to the tracker, with status FIXED, but he quoted the wrong text: he mentioned the centering bug instead.

4) There is possibly a "dynamic vs static" bug, discussed in this same thread, when showing multiple text labels, some printing things like $FOO$ (originally empty) and others printing static text, which end up overlapping again... this is NOT in the tracker yet but it might be the same as bug 4600 or as bug 4632, or a combination of the two.. (see test module in this thread for this as well).

5) There is a "delayed" bug with text labels which print things like $FOO$ and don't get updated till every other command (e.g. GKC's) is fully resolved, whatever the position of the Set Global Property or Dynamic Property trait that changes the value of $FOO$ is in the trait order. This is NOT in the tracker yet (and I think there is an exact similar issue with the Layer trait not refreshing till the very end).

6) There is a hard to pin point "timing" bug with trying to have a scrolling log made of multiple text labels printing things like $LOGLINE1$, $LOGLINE2$ etc which shows up when the command moving LOGLINE2 to LOGLINE1 (i.e. scroll up) sometimes does not happen (the new LOGLINE2 text gets overwritten over the old one). NOT in the tracker (and might be related to issue (5) above).
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

Re: Text labels in 3.2.0: bug or feature?

Postby Brent Easton » October 9th, 2012, 10:03 pm

Ok,

I have found and fixed the centering problem. This was quite straight forward, when the text changed, the position of the label was not being recalculated. This is bug 4322.

I believe most of the rest of the bugs relate to the incorrect way you use Text labels barbanera. On reflection, I believe the fix I made for 4632 was incorrect and that the way it was before (that caused your overlapping labels problem) was correct.

If two labels are defined with the same offsets then they should appear in the same place. Full stop.

If you want labels to appear on different lines, then you should be specifying an offset in the label to make them appear on different lines.

The fact that labels with no key command happen to appear on multiple lines in the past was basically a bug in my view that should have been squashed as soon as it appeared.

Regards,
Brent.
User avatar
Brent Easton
 
Posts: 3176
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Text labels in 3.2.0: bug or feature?

Postby Brent Easton » October 9th, 2012, 11:11 pm

2) There is a "unselectable" bug with text labels on pieces which have no imaged defined, reported as bug 4600, but the jury
is still out on this (bug or no bug? feature request?).


Bug 4600 was closed as Won't Fix. There is a standard way to achieve what you are trying to do.

5) There is a "delayed" bug with text labels which print things like $FOO$ and don't get updated till every other command (e.g. GKC's) is fully resolved, whatever the position of the Set Global Property or Dynamic Property trait that changes the value of $FOO$ is in the trait order. This is NOT in the tracker yet (and I think there is an exact similar issue with the Layer trait not refreshing till the very end).


I'm not sure why this is significant. As long as at the end of the command stream, the appropriate labels are displayed, what is the problem?

The actual time that any image is redisplayed under java is out of our control, we can only request Swing to refresh a screen area or component, the actually timing of refreshes is handled by Java. If you are trying to implement some type of animation effect through Vassal Key Commands, you are doomed to failure.

Regards,
Brent.
User avatar
Brent Easton
 
Posts: 3176
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Text labels in 3.2.0: bug or feature?

Postby uckelman » October 10th, 2012, 10:46 am

Thus spake Brent Easton:
> Ok,
>
> I have found and fixed the centering problem. This was quite straight
> forward, when the text changed, the position of the label was not being
> recalculated. This is bug 4322.

Fixed in 3.2.0-svn8417. Try that.

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

Re: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 10th, 2012, 1:55 pm

Brent Easton wrote:I believe most of the rest of the bugs relate to the incorrect way you use Text labels barbanera. On reflection, I believe the fix I made for 4632 was incorrect and that the way it was before (that caused your overlapping labels problem) was correct.

If two labels are defined with the same offsets then they should appear in the same place. Full stop.

If you want labels to appear on different lines, then you should be specifying an offset in the label to make them appear on different lines.


Brent, I wholeheartedly agree. Indeed, I made an attempt (back in January) to properly define offsets. However, and here is the catch, then there is a bug with offsets. Or maybe I don't understand how to use offsets..

Piece with multiple text labels:

1) first text label at default vertical offset 0

2) second text label at 10

3) third text label at -10

All the rest being equal (default selection for alignment etc) they should appear one on top of the other 10 pixels a part, correct? They don't. And they didn't work properly even in early builds of 3.2.0, that is before your fix to revert to 3.1.x automatic line feeding style.

That's why I was happy with the 3.1.x behavior that automatically added line feeds between them. It was contrary to the whole point of having offsets, sure, but then please fix the offsets situation or tell me what I am doing wrong :)

Anyway, there is an obvious drawback to having to calculate and define offsets (when they actually work): you can't just add another text label and/or change the respective font size of the existing ones without having to go through a whole bunch of calculations and one-by-one fiddling.

Maybe giving the piece component a "do not stack text labels" (or "add automatic line feeds between text labels") check-able attribute would be nice. Or perhaps make it a map or module level property..
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

Re: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 10th, 2012, 2:13 pm

Brent Easton wrote:
2) There is a "unselectable" bug with text labels on pieces which have no imaged defined, reported as bug 4600, but the jury
is still out on this (bug or no bug? feature request?).


Bug 4600 was closed as Won't Fix. There is a standard way to achieve what you are trying to do.


Yes, I know, the invisible gif. But then one has to predetermine needed length of the invisible gif and keep changing it whenever he changes his mind about the string to display. I think this is cumbersome and ugly and needlessly adds (potentially) tons of small invisible gifs to the module. But of course it is hard to implement otherwise then I am pretty happy with the ugly workaround, it's not a crucial issue at all.

Brent Easton wrote:
5) There is a "delayed" bug with text labels which print things like $FOO$ and don't get updated till every other command (e.g. GKC's) is fully resolved, whatever the position of the Set Global Property or Dynamic Property trait that changes the value of $FOO$ is in the trait order. This is NOT in the tracker yet (and I think there is an exact similar issue with the Layer trait not refreshing till the very end).


I'm not sure why this is significant. As long as at the end of the command stream, the appropriate labels are displayed, what is the problem?

The actual time that any image is redisplayed under java is out of our control, we can only request Swing to refresh a screen area or component, the actually timing of refreshes is handled by Java. If you are trying to implement some type of animation effect through Vassal Key Commands, you are doomed to failure.


I have a "Click here to start the game" piece with an action button which a player in a network game pushes to initiate a complex setup process. What I am trying to achieve is for the button itself to revert to "... game starting, please wait.." and then to proceed to the actual setup (which takes a minute or so) before deleting itself.

I tried using a Layer or a Text label which follow the value of a Dynamic Property called "Status" defined on the piece (tried also with a global property) and having the action button first thing change it from 0 to 1, before proceeding to invoke the rest of the setup procedure via a bunch of triggers.

The problem is that people (including the player pushing the button) won't ever see the "... game starting, please wait.." image/string because it won't change till the very end, when it actually deletes itself. Thus, players will keep pushing the button not knowing if the game started or not till the very end. No way to achieve this then, I gather? I also tried Replace with Other, but no cigar.

Moreover, remote players will not even get the update of the "Status" DP/GP from 0 to 1 till the very end, so that they will disrupt the setup procedure by initiating it themselves while setup is already in progress (resulting in out of synch setups). But I guess this is another story.. (wish somebody had a clue how to solve it.. how to force a resynch on the fly..).
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

Re: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 10th, 2012, 2:29 pm

uckelman wrote:Thus spake Brent Easton:
> Ok,
>
> I have found and fixed the centering problem. This was quite straight
> forward, when the text changed, the position of the label was not being
> recalculated. This is bug 4322.

Fixed in 3.2.0-svn8417. Try that.
.


Confirm centering bug fixed, thanks!
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

Re: Text labels in 3.2.0: bug or feature?

Postby Tim M » October 10th, 2012, 2:56 pm

barbanera wrote:I have a "Click here to start the game" piece with an action button which a player in a network game pushes to initiate a complex setup process. What I am trying to achieve is for the button itself to revert to "... game starting, please wait.." and then to proceed to the actual setup (which takes a minute or so) before deleting itself.

I tried using a Layer or a Text label which follow the value of a Dynamic Property called "Status" defined on the piece (tried also with a global property) and having the action button first thing change it from 0 to 1, before proceeding to invoke the rest of the setup procedure via a bunch of triggers.

The problem is that people (including the player pushing the button) won't ever see the "... game starting, please wait.." image/string because it won't change till the very end, when it actually deletes itself. Thus, players will keep pushing the button not knowing if the game started or not till the very end. No way to achieve this then, I gather? I also tried Replace with Other, but no cigar.

Moreover, remote players will not even get the update of the "Status" DP/GP from 0 to 1 till the very end, so that they will disrupt the setup procedure by initiating it themselves while setup is already in progress (resulting in out of synch setups). But I guess this is another story.. (wish somebody had a clue how to solve it.. how to force a resynch on the fly..).


Change your method and force it to pause instead at the "game starting please wait" by requiring the user to click the action button again and changing what the text says so you might have

step 1 - "Click here to Setup Game"
step 2 - "Setup complete - Click here again to begin play"
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: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 10th, 2012, 5:55 pm

Tim M wrote:Change your method and force it to pause instead at the "game starting please wait" by requiring the user to click the action button again and changing what the text says so you might have

step 1 - "Click here to Setup Game"
step 2 - "Setup complete - Click here again to begin play"


Hmm, how would this solve the problem?

The problem is the actual lengthy setup, which you suggest to do in step 1. How would everybody (including the clicking player) know the button was actually pressed till the very end if there are no visual clues about it right away? This is just the original issue. It is not crucial in solo mode (just a bit ugly): after all restrict commands are in place to block the player from clicking multiple times. However, in network play it completely breaks the game if some remote player bona fide clicks "start game" again (no visual clue, no update yet of the DP/GP tracking the click).

Similarly, if step 1 is just a label replacement (from "Start game" to "click to continue") the problem will again arise exactly as before in step 2.
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

Re: Text labels in 3.2.0: bug or feature?

Postby tar » October 10th, 2012, 6:02 pm

On Wed, Oct 10, 2012 at 6:55 AM, barbanera wrote:

> Anyway, there is an obvious drawback to having to calculate and define
> offsets (when they actually work): you can't just add another text label
> and/or change the respective font size of the existing ones without
> having to go through a whole bunch of calculations and one-by-one
> fiddling.
>

Yes, that is a problem with absolute layouts in general.
But short of having some sort of automatic layout definition, it isn't easy
to solve.

One solution to the font size issue, though, is to allow font-relative
units to be used. Something like "ex" and "em" for spacing. IIRC the
JGoodies layout manager has a provision for that based on Microsoft's (?)
"dlu" (dialog units) measurement.
User avatar
tar
 
Posts: 776
Joined: January 2nd, 2008, 6:53 pm
Location: Los Angeles area

Re: Text labels in 3.2.0: bug or feature?

Postby Tim M » October 10th, 2012, 6:21 pm

Look at what I did in the Urban Sprawl module - click on the 2 setup deck
buttons and watch the chat window and what the buttons do. Exactly what you are
trying to do here. Use the chat window to communicate the internal process -
everyone will see it




________________________________
From: barbanera
To: messages@vassalengine.org
Sent: Wed, October 10, 2012 12:55:47 PM
Subject: Re: [messages] [Developers] Text labels in 3.2.0: bug or feature?


"Tim M" wrote:
>
> Change your method and force it to pause instead at the "game starting
> please wait" by requiring the user to click the action button again
> and changing what the text says so you might have
>
> step 1 - "Click here to Setup Game"
> step 2 - "Setup complete - Click here again to begin play"


Hmm, how would this solve the problem?
The problem is the actual lengthy setup, which you suggest to do in step
1. How would everybody (including the clicking player) know the button
was actually pressed till the very end if there are no visual clues
about it right away? This is just the original issue. It is not crucial
in solo mode (just a bit ugly): after all restrict commands are in place
to block the player from clicking multiple times. However, in network
play it completely breaks the game if some remote player _bona fide_
clicks "start game" again (no visual clue, no update yet of the DP/GP
tracking the click).

Similarly, if step 1 is just a label replacement (from "Start game" to
"click to continue") the problem will again arise exactly as before in
step 2.

_______________________________________________
Read this topic online here:
viewtopic.php?p=36538#p36538
_______________________________________________
messages mailing list
messages@vassalengine.org
http://www.vassalengine.org/mailman/listinfo/messages
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: Text labels in 3.2.0: bug or feature?

Postby barbanera » October 10th, 2012, 7:30 pm

I looked and noticed the following differences:

1) Your setup takes less than a second while mine takes much longer (kudos to you!)

2) Your setup doesn't mess with text labels and layers, using report actions instead

3) Your setup doesn't even bother storing the info that it was started (it being so fast, I guess)

4) I wonder what would happen if your green, white, red etc players would all happen to click on setup at the same time though..

I guess your setup happens fast enough not to bother about issue 4. However, I do have that problem, as my setup takes 20 seconds.. Yes, I could use report traits to let everybody know the setup is in progress, but that means trusting everybody to pay close attention and not be tempted to hit "start game"..

Moreover, it's difficult for me to understand why a layer or text label will be updated whenever Swing feels up to it, while report traits would be sent across the network right away..
barbanera
 
Posts: 395
Joined: January 12th, 2012, 2:27 pm

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 2 guests