size change of miltary building windows when mouse over soldier's icons

Thank you for the report. Note: In the future, please consider uploading screenshots instead of a video. They are smaller and more convenient. For example, you could have just taken two screenshots and copied the different states of the window into a single image in an editor for easy comparison.

As for the bug itself, I just never noticed it because I'm always using debug builds, in which the additional debug button makes the window wider and the problem doesn't appear. It's definitely something we should fix, though.

Well, I think this is so annoying that we should fix it for build 16. We will get tons of bug reports otherwise.

Okay -- point taken about the waste of size.
While you are at it.... Wouldn't a numeric display of the soldier's health points (when mouse over) also be welcome?

Attachment changed from video to still in order to save space

Fixed in r5870.

Playing bzr5873 there is still a small but noticible size change in the window for me.

I cannot reproduce this with a release build using bzr5888. I checked the barbarian sentry and citadel. For me, the window size does not change. I therefore set this back to fix committed. Please give a more detailed description of how you see the size jumping, which tribe, which building and so on. Or even provide a savegame with the building that makes trouble.

I am still using bzr5882, but it should not matter.

I can see this with all military sites of all tribes.
The lower the resolution, the more it gets noticible.

It's in fact about 1 pixel.
It can best be seen with the imperial castle.
I have attached a picture to demonstrate

I cannot reproduce this. I attach a montage of my system (r5891, mac os x, 640x480 fullscreen, open gl renderer).

Can you update and check again? If this persists, can you post screen resolution, fullscreen or not, renderer, and all details you can remember).

This is _very_ strange!

I have updated to bzr5886 and installed into a new subdir.
Nothing changed, except SDL.DLL in order to be able to alt tab out and take notes.

I was re-checking at 800x6000x32 and loaded a savegame.
Here I found two barbarian citadels - one showing the size change, another one did not.
The diffenrce is the soldier in there.
I looks like EV untrained soldiers make the line longer, The "0" takes more space.
I am trying to find out more, but wanted to let you know.
I will try with a new game next.

The combinations are bit much to try all, since I must stop for today, but I can say this much:
Resolution does not matter, nor does Full Screen or not.
Font in WL does not seem to matter. (not quite sure) Is there really a difference for the
Soldiers properies line in question?

The type of building does matter.
I have not seen a width change for fortresses (neither barbarian nor empire),
but always for Sentry (both tribes) Donjon/Tower and Citadel/Castle.
For the buildings where width change occurs It is not a yes or no, but the amount of change also depends on the values that need to be displayed. So there is a size change within the same building when you mouse over soldiers with different values.
Since WL usually only produces certain training level, I might need to kick out soldiers manually for the
in-betweeens.

What other information would you want?
What is the renderer you spoke of?
Need hardware info? (NVidea GeForce 275 GTX)

Regarding buildings everything seems clear now. No further combinations are needed, methinks. But it would be helpful if you could provide the savegame with the two citadels for comparision on my system.

Could you check if Options -> Advanced Options -> Enable OpenGL makes a difference for you. That is what I mean with renderer: opengl or software.

Btw: this bug is 'fixed enough' to be no show stopper for build 16rc1. If we can fix it beforehand, good. If not, we will retarget as the one pixel jump are only a minor nuisance and not as critical as the original bug. Do you agree?

Very well,
OpenGl enabled or not does not change the width jump.
I've doen some testing for 800x600x32 with untrainded soldiers.
The buildings:
Atlantean Tower
Barbarian Fortress
Empire Barack
Empire Outpost
Empire Fortress
are the only ones _not_ showing the width jump; all other do.

Savegame attached.
Look for the single Gold mine in the middle of the mountain range.
From there,
the first citadel to the north-west (one EV trained soldier; no jump)
and the first citadel to the south west (one untrained soldier; jumping)
are the ones in question.

And of course I'm d'accord with not letting this stop build 16.
This phantastic game comes for free, and, by the work of this team is getting better every day.
Who in his right mind would complain about anything?

@SirVer: Why is the background of the soldiers list in your game white? It's supposed to be black. Very odd. Does OpenGL vs. software rendering make a difference?

On-topic: The way I've fixed this bug is to pre-compute the width of the soldier stats text. It is possible that this pre-computation is too conservative, and I happened not to notice because it's only a single pixel. It is also possible that - because this pre-computation works by computing the length of a line of text - subtle differences in font rendering libraries cause the difference. For example, if the freetype algorithms for kerning were tweaked between different versions, this might be enough to cause a one pixel difference.

@Astuur: Can you please try going to src/wui/soldierlist.cc, line 395, and change the "HP: 8/8 AT: 8/8 DE: 8/8 EV: 8/8" to let's say "HP: 8/8 AT: 8/8 DE: 8/8 EV: 8/8@". This should introduce enough slack to make the problem go away, but I'd like to get a confirmation on that.

None of the citadels jump for me in your savegame. I also think that nicolai is on the spot with his analysis.

@nicolai: in game the soldiers background is indeed black, when I take a screenshot with "Screen capture" which is the Mac delivered program it stays black. If I use CTRL + F11 it turns white in the screenshot, I didn't notice any other color change. This is with opengl enabled. In the software renderer, both mechanism produce the correct screenshot.

Nicolai, I depend and someone to compile and package all the stuff.
No compiler here (neither any knowledge about the how-to)
I have been using Tino's W32 8-schuss packages so far.
If your fix has made it into one of them, I will gladly try.
Should I be wrong, or able to receive a widelands.exe
containing your fix from somewhere, please tell me.

I commited the change from #17 in r5895. this is small enough a fix to not cause any harm. I set this to fix commited. Can you verify it is indeed astuur?

Will do and report back as soon as I can lay my hands on a compiled .exe.

it's perfect now for me with bzr5895!

Released in build16-rc1