Building window background "jumping" when previewing upgrade build cost

Bug #1019585 reported by Hans Joachim Desserud
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
widelands
Fix Released
Medium
Gabriel Margiani

Bug Description

The required build cost is now previewed when hovering the cursor over a building to be built or enhanced (bug 740401). First, off all; awesome, thanks a lot! I've been waiting for this a long time.

Then to the issue:
1. Start a new game as barbarians.
2. Build a metalworks.
3. When it has finished, open the building window.
4. Hover the cursor over the "enhance building" button.

As expected, the build costs for the enhancement is shown at the bottom of the window. However, adding this row of items increase the height of the window, thus the background image of the building is shifted down to remain centered which makes it seem like it is jumping.

I guess this was ok when the window remained static, but now that the window size can change, we might want to reconsider this option. The background window should not be moving around for random reasons when the user is interacting with the window. Perhaps we could position it when the window is opened based on the original window size and then lock it so that it is unaffected by any changes in window size? (I don't know how well that would work for buildings with larger images, such as castles and battle arenas.)

Related, but less annyoing; it is also possible to see the changes in how the window pattern on the sides match up when the build costs are shown/hidden.

Tags: ui

Related branches

Revision history for this message
SirVer (sirver) wrote :

I was expecting this bug report :P. I personally also dislike the changing of the window size. I would prefer if the UI already reserved some space for the information that could be displayed. The same space could also be used to display a short help text when hovering the other buttons (instead of the tooltip we currently have).

What do others think? Does anybody else find the changing of window sizes straining?

Changed in widelands:
status: New → Confirmed
Revision history for this message
Hans Joachim Desserud (hjd) wrote :

>I was expecting this bug report :P.
Yes, I've now seen you mentioned this back in the code review.

As for reserving the space at the bottom, I don't know. Beyond building upgrades, the other buttons should be straight forward and their icon/tooltip texts sufficient. I'm aware that for instance VirtualBox has a box like this to display information regarding various settings, but then again that's more advanced information which span 1-2 sentences. Seems to me, that we would set up lots of empty space we don't really use for anything useful when not displaying the build costs.

Revision history for this message
SirVer (sirver) wrote : Re: [Bug 1019585] Re: Building window background "jumping" when previewing upgrade build cost

How about moving the buildcost/return cost into the tooltip? This will
be possible with the new text renderer I am currently working on.

Revision history for this message
Hans Joachim Desserud (hjd) wrote :

Could be worth a try, if for nothing else then to see how it works in comparison.

Revision history for this message
Borim (borim) wrote :

The variable size of the window cause also another problem. When the building window is near the button of the main window border, the building window jumps.
Steps to reproduce:
1) open any building window
2) move the window down to the bottom of the main window
3) hover the mouse over the dismantle button

This is very annoying if you want to dismantle a building. You need to click two times, as due to the jump you miss the dismantle button.

Revision history for this message
Shevonar (shevonar) wrote :

The issue Borim reported in comment #5 was reported as a separate bug which I marked as duplicate since it hast the same root cause.

Revision history for this message
Joachim Breitner (nomeata) wrote :

Have you considered calculating the position of the background once (when the window is first created) and just leave it there no matter how the window is resized?

Window resizing happens in many more places, e.g. production sites with their varying ware queue number and length, so a solution that allows window resizing would be useful.

Revision history for this message
Hans Joachim Desserud (hjd) wrote :

See also bug 1100310 for the issue described in comment #5. While somewhat related, I don't think they really describe the same issue. The jumping window only happens when it is close to a border while the background will "move" no matter where the window is placed. I also think it would be possible to fix one without touching the others, therefore I don't really consider them duplicates. (I won't mind someone fixing both issues at once though :) )

Revision history for this message
Gabriel Margiani (gamag) wrote :

I'l try to move it to the tooltip..

Changed in widelands:
assignee: nobody → Gabriel Margiani (gamag)
Revision history for this message
SirVer (sirver) wrote :

That should be easy now - the new rt renderer is used for tool tips and you can use its full powers making tables and including images. Have a look at the examples in tests/richtext/tests.

Revision history for this message
Gabriel Margiani (gamag) wrote :

The main problem seems to be the fieldactionwindow since IconGrid doesn't support tooltips.

Revision history for this message
SirVer (sirver) wrote :

You can add it easily to IconGrid button - and just pass it down in the constructor. Should be straight forward :-)

Revision history for this message
SirVer (sirver) wrote :

Merged Gabriels work in r6495. He found a nice solution of moving the data to the tooltip: The window is never wasting space but also doesn't need to get resized.

Changed in widelands:
status: Confirmed → Fix Committed
Revision history for this message
SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.