Multiple tooltips may be shown when opening building information

Bug #657285 reported by Hans Joachim Desserud on 2010-10-09
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

Steps to reproduce:
1. Start a new game. (I've chosen barbarians for this example)
2. Build a building that produce something for other buildings, for instance a tavern. (This is just to be sure to have a hover-text)
3. Move the cursor over the building. The hover-text will display something like "Skipped produce ration because economy does not need ration"
4. Click on the building to open building information.
5. Move the cursor over any of the resources or some of the buttons in the building information.

Actual result:
The correct hover-text for the resources or buttons in the building information dialog will be shown, in addition the hover-text for the building is shown behind the dialog. This leads to two separate hover-texts being shown, one partially hidden.

Expected result:
I expect only one hover-text to be shown, the one in the current dialog.

It seems to me, the building does not register when the dialog is opened and continue to show the hover-text. Perhaps opening the dialog should trigger the same event as when moving the cursor away (mouse_out?).

Widelands bzr rev 5563 on Ubuntu 10.04.

Tags: ui Edit Tag help

Related branches

SirVer (sirver) on 2010-10-09
Changed in widelands:
status: New → Confirmed
importance: Undecided → Low
summary: - Multiple hover-texts may be shown when opening building information
+ Multiple tooltips may be shown when opening building information
tags: added: ui
Changed in widelands:
milestone: none → build18-rc1
Changed in widelands:
assignee: nobody → cghislai (charlyghislain)
status: Confirmed → In Progress
Hans Joachim Desserud (hjd) wrote :

I'm still able to reproduce this issue, even after the attached branch was merged in r6629. See the attached screenshot. Might be slightly trickier, but if you move the open window to overlap the building, you should be able to trigger it.

PS. The missing parts of the screenshot are reported as bug 1202146.

In general, you seem to have done a great job fixing bugs lately. That said, I think it would be better to submit separate branches/merge requests for each bug rather than gathering lots of fixes in one giant merge. First of all, it makes it easier to get an overview as all changes are related to a single issue. If there are any problems with the suggested patch, we can get those sorted out while merging the fixes for other bugs so that they don't get delayed in the mean time. It also makes it clearer to see what was fixed in a particular commit, for instance I don't know if all bugs linked to the branch recently merged can be set to Fix Committed or if only some of them can. If a bug is introduced by a particular commit, it is easy to look up what really changed in the future if the set of changes is smaller.

If bugs are closely related it would of course make sense to fix them at the same time, but if they are affecting unrelated parts of the code it is usually better to file separate merge requests (or alternatively wait until the first fix is in).

Keep up the good work. :)

cghislai (charlyghislain) wrote :

I confirm, I will look into that later, I have my idea on the fix.

I will push branches separately for bugs fixes in the future. It is just that i am low on disk space, so I tried to make a single commit for each bug in that branch. But I will clean my hard drive.

SirVer (sirver) on 2013-07-20
Changed in widelands:
status: In Progress → Fix Committed
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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers