Weird shape showing in toolbar in 3.2.0 beta2+

I just noticed that with 3.2.0 beta 2 or later builds there is a weird spurious shape showing up on the toolbar of the main window. I tried with beta 2, build 8355 and build 8361.

No such spurious shape with 3.1.18 or 3.2.0 beta 1 or build 8313.

Please see following snapshots, the “ok” one was taken with 3.1.18 (but similar display with beta 1 and 8313) and the “weird” one with build 8355 (but similar display with beta 2 and 8361). Note the weird extra almost transparent rectangular shape to the right of the camera image in the build 8355 snapshot. Don’t pay attention to the small square box to the left of the camera (it is a turn counter with no text defined).

I tried removing the camera feature from the module but the weird shape remains. It’s a real feature because if one expands the turn counter to “dock in the toolbar” (from the Preferences) the weird shape pushes the camera image on a second line of the toolbar, at least in my 1366x768 laptop screen.

What gives?

I completely wiped out the AppData/Roaming/Vassal/Tiles folder and restarted Vassal 3.2.0 build 8355 loading Marvel Heroes v1.2. The spurious extra rectangular feature in the toolbar is still there. Darn ugly and annoying if it forces other buttons on a 2nd line (as when I reduce the window size).

I tried with 8313 again and I can confirm the shape is not showing. The situation is as in the two snapshots shown in the previous message. Actually, now that I look more closely at the first image above (taken with 3.1.18 but identical with beta 1 or 8313) there is a much smaller but still visible skewed white fudge to the right of the camera image. Nothing as disturbing as in the beta2/8355 case, though.

Any clue?

Thus spake barbanera:

I completely wiped out the AppData/Roaming/Vassal/Tiles folder and
restarted Vassal 3.2.0 build 8355 loading Marvel Heroes v1.2. The
spurious extra rectangular feature in the toolbar is still there. Darn
ugly and annoying if it forces other buttons on a 2nd line (as when I
reduce the window size).

I tried with 8313 again and I can confirm the shape is not showing. The
situation is as in the two snapshots shown in the previous message.
Actually, now that I look more closely at the first image above (taken
with 3.1.18 but identical with beta 1 or 8313) there is a much smaller
but still visible skewed white fudge to the right of the camera image.
Nothing as disturbing as in the beta2/8355 case, though.

Any clue?

It doesn’t have anything to do with tiles. The thing you’re seeing is
a JToolBar, I believe.


J.

And whatever is a JToolBar? I doubt it is something supposed to be there as it was not showing in previous builds :slight_smile:

docs.oracle.com/javase/1.4.2/doc … olBar.html

Probably more than and all you ever wanted to know about JToolbar :slight_smile:

Ahh, you mean it is not a Joel toolbar then? ;)

Needless to say the real question is whatever is that JToolBar there for? Previous builds did much better without, I think.

It might be a JToolBar or a hyerarchical attribute from the outermost layer in the compiler framework inherited from the parent class in in the Bean Shell current gobbledeedok… but in poor man jargon this just sounds like something went wrong in the latest builds ;)

Thus spake barbanera:

And whatever is a JToolBar? I doubt it is something supposed to be there
:slight_smile:

The JToolBar is there in both of your screenshots. It’s just wider in
the second one. You can see it in the first one by the line which is
beneath screenshot button.

The commit which caused the change is probably 8339. I would argue that
neither of these is really correct—that button shouldn’t be wrapped
in a JToolBar at all. This is something I’ve tried to correct before
without success.


J.

Thus spake Joel Uckelman:

Thus spake barbanera:

And whatever is a JToolBar? I doubt it is something supposed to be there
:slight_smile:

The JToolBar is there in both of your screenshots. It’s just wider in
the second one. You can see it in the first one by the line which is
beneath screenshot button.

The commit which caused the change is probably 8339. I would argue that
neither of these is really correct—that button shouldn’t be wrapped
in a JToolBar at all. This is something I’ve tried to correct before
without success.

The fundamental problem here is that the UI is being used to store
configuration data. The way that the Player window finds the buttons
belonging to a docked Map is by asking the map for its toolbar, and
sticking the latter into the former. Because it was designed this way,
there’s no way for the Editor to determine which buttons came from the
Map if it needs to remove them, except by asking the Map for its toolbar
and removing that. We could independently track a list of Map buttons,
but the problem there is thabuttons are added to the Map’s toolbar
directly, so the Map also has no idea what buttons belong to it.

I believe this approach was taken at the beginning becuase it seemed
easier, but it was never the right thing to do. I think anything which
produces the correct behavior will either be a brittle, ugly hack or
require a near total overhaul of how the UI is constructed from module
data.

If someone else wants to try fixing this, great, but the perceived
effort goes beyond what I fell justified in undertaking to fix a
cosmetic problem in V3 when I could put the same effort into V4.


J.

Joel, it’s not a great deal to me, after all having everything in one line or in two in the toolbar is screen resolution dependent. For sure not something worth spending developing time if it’s indeed so complex as you suggest.

Having said that, why exactly this unwanted side effect came along with build 8339? Is it not possible to take a fresh look at whatever fixed were introduced in build 8339 and rework them out in light of this issue? In other words, make the involved developer(s) aware that this side effect was produced and he/she might fix whatever he/she did.

Thus spake barbanera:

Having said that, why exactly this unwanted side effect came along with
build 8339? Is it not possible to take a fresh look at whatever fixed
were introduced in build 8339 and rework them out in light of this
issue? In other words, make the involved developer(s) aware that this
side effect was produced and he/she might fix whatever he/she did.

Are you putting other buttons which don’t have icons into the map
toolbar? It reported that it has 10 children when I checked on it with
your MH module.


J.

Yes, I think I have indeed 10 “hidden” buttons in the main map toolbar:

  1. the main map window (called Game Board) itself has 9 global key commands without text;

  2. towards the end of the module (in the editor display) there is another window (called DEBUG) defined and in order to avoid it being displayed as a button in the main map’s toolbar, just before it I added a Toolbar Menu (JToolBar?) with no text, to contain DEBUG (and also Game Progress, which is the name I gave to the one turn counter in the module: alas, that fails to follow the JToolBar orders and is stubbornly staying visible).

Thus spake Joel Uckelman:

Thus spake barbanera:

Having said that, why exactly this unwanted side effect came along with
build 8339? Is it not possible to take a fresh look at whatever fixed
were introduced in build 8339 and rework them out in light of this
issue? In other words, make the involved developer(s) aware that this
side effect was produced and he/she might fix whatever he/she did.

Are you putting other buttons which don’t have icons into the map
toolbar? It reported that it has 10 children when I checked on it with
your MH module.

I think “hidemode 3” is needed for the MigLayout the Map’s JToolBar
uses. Try 3.2.0-svn8374, and check whether your key commands with hidden
buttons still work.


J.

Everything is apparently back to normal and working all right with 8374, thanks!

While you are looking into JToolBars… any chance turn counters could be hidden by them too, same as maps?

Thus spake barbanera:

While you are looking into JToolBar’s… any chance turn counters could
be hidden by them too, same as maps?

I don’t understand what you’re asking.


J.

As in the brief description of the MH module above, I have a Turn Counter - called Game Progress - in the module. I was hoping the same no-name/no-text Toolbar Menu which is hiding the DEBUG Map Windows would also hide the Turn Counter. Alas, it doesn’t. See bottom of the MH module in the editor.

Any chance Turn Counter(s) could be included in Toolbar Menus and thus, if one wishes, completely hidden?

Thus spake barbanera:

As in the brief description of the MH module above, I have a Turn
Counter - called Game Progress - in the module. I was hoping the same
no-name/no-text Toolbar Menu which is hiding the DEBUG Map Windows
would also hide the Turn Counter. Alas, it doesn’t. See bottom of the MH
module in the editor.

Any chance Turn Counter(s) could be included in Toolbar Menus and thus,
if one wishes, completely hidden?

I still don’t understand what you’re talking about. I don’t see a Turn
Tracker appearing in any of the accessible windows.


J.

It’s the small empty square next to the camera image (see snapshots above). Just click on it.

Or go to Preferences → Turn Counter → Dock in the toolbar

I would like to be able to hide it completely from the casual gamer (some hotkey to pop it up for testing, I guess) in both cases (free floating or docked).

Thus spake barbanera:

It’s the small empty square next to the camera image (see snapshots
above). Just click on it.

Or go to Preferences → Turn Counter → Dock in the toolbar

I would like to be able to hide it completely from the casual gamer
(some hotkey to pop it up for testing, I guess) in both cases (free
floating or docked).

I believe a small change to TurnTracker will do what you want. At line
368, we change

launch.setVisible(!dock);

to

launch.setVisible(
!dock && (
getAttributeValueString(BUTTON_TEXT).length() > 0 ||
getAttributeValueString(ICON).length() > 0
);

Brent, does this look ok to you?

J.

On 25/09/2012 6:53 AM, Joel Uckelman wrote:

Thus spake barbanera:

It’s the small empty square next to the camera image (see snapshots
above). Just click on it.

Or go to Preferences → Turn Counter → Dock in the toolbar

I would like to be able to hide it completely from the casual gamer
(some hotkey to pop it up for testing, I guess) in both cases (free
floating or docked).
I believe a small change to TurnTracker will do what you want. At line
368, we change

launch.setVisible(!dock);

to

launch.setVisible(
!dock && (
getAttributeValueString(BUTTON_TEXT).length() > 0 ||
getAttributeValueString(ICON).length() > 0
);

Brent, does this look ok to you?
Sounds good.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Thus spake Brent Easton:

On 25/09/2012 6:53 AM, Joel Uckelman wrote:

Thus spake barbanera:

It’s the small empty square next to the camera image (see snapshots
above). Just click on it.

Or go to Preferences → Turn Counter → Dock in the toolbar

I would like to be able to hide it completely from the casual gamer
(some hotkey to pop it up for testing, I guess) in both cases (free
floating or docked).
I believe a small change to TurnTracker will do what you want. At line
368, we change

launch.setVisible(!dock);

to

launch.setVisible(
!dock && (
getAttributeValueString(BUTTON_TEXT).length() > 0 ||
getAttributeValueString(ICON).length() > 0
);

Brent, does this look ok to you?
Sounds good.

Thanks for checking. This has been reported as Bug 4818, and fixed in
trunk@8379.


J.