Numeric wares display in warehouses not updating correctly

Bug #726139 reported by Astuur on 2011-02-27
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
widelands
Medium
Unassigned

Bug Description

Pertains to bzr5873 (Win package: Imperial)
There is a problem with the update of opened warehouse windows. When the window is open, none of the numbers displaying the amount of each ware will be updated until you hover the cursor over it, even if your workers are carrying various wares in and out of your HQ/warehouse.
To reproduce: collect all soldiers in one warehouse. Keep its window open. Then set this warehouse to the "no further storage" policy for soldiers; another warehouse to "store preferred". Then demand new soldiers by kicking out some existing ones from your military sites. DO NOT mouse over the window of the emptying warehouse.
You will see soldiers leaving this warehouse, but the numeric display will not change.
Sometimes it will update when you mouse over the warehouse window; sometimes it will not even then.
At other times it will update suddenly without particular reason.

Tags: ui Edit Tag help

Related branches

Astuur (wolfsteinmetz) on 2011-02-27
description: updated
Hans Joachim Desserud (hjd) wrote :

I see the same thing here. Actually a quicker way to reproduce it is to open HQ, then build military building and watch the number of soldiers remain the same as they leave.

I guess the reason is that the values are not updated often enough to reflect the recent change. I'm sure there was another bugreport mentioning something similar (bug 580073?).

Changed in widelands:
importance: Undecided → Low
status: New → Confirmed
tags: added: ui
Astuur (wolfsteinmetz) wrote :

The problem also occurs with the stock window (wares in warehouses)

description: updated
Joachim Breitner (nomeata) wrote :

The reasons is that windows are cached by default. For example, adding "set_cache(false)" in the WareHousesWaresDisplay fixes the problem there.

One solution could be to add this line of code to the constructor of Building_Window, where it would fix such issues in every case of a building window showing varying information, but I am not sure about the performance penalties.

The proper solution would be to call update() on the window when something changes in the building, but I’m not sure what codepath can provide that, given that the UI is somewhat separate from the logic code.

Hans Joachim Desserud (hjd) wrote :

Multiple people have noticed this bug independently now, so I consider it likely players will notice it as well.

Btw, could whoever ends up dealing with this, check whether bug 902464 and bug 952429 are simply duplicates of this?

Changed in widelands:
importance: Low → Medium
milestone: none → build18-rc1
Hans Joachim Desserud (hjd) wrote :

As discovered in bug 952429, this also affects the ports windows, which I assume are identical with the HQ/warehouse ones.

Joachim Breitner (nomeata) wrote :

I’m wondering if it is a good idea to have a very general and very simple signal mechanism from the logic code to the ui code, i.e. a ui object can register with a logic object and then the logic object will call ::update() on the ui object whenever it has changed.

This would allow this bug to be easily fixed and greatly simplify existing code, e.g. in WaresQueueDisplay, which keeps copies of all attributes of the logic object to compare them for changes.

But then I vaguely recall from WiHack that signals were for some reasons not quite welcome – is that true, and what was the reason?

Joachim Breitner (nomeata) wrote :

I have pushed a branch that implements this using a boost::signal; the code is very straight forward; the effect though is very nice and slick – when a worker enters the building it updates so fast that I don’t even see the number changing.

SirVer (sirver) wrote :

I actually have a Observer/Observable class in one of my dangling branches (The one working on the editor), so I agree that it is kinda useful to have.

Your branch renamed build/ which I guess was not intentional. I reverted this before merging. I am also not terribly happy with having the signal being mutable inside the WaresList. It means for one that we can only have one Ui element watching any WaresList and secondly having mutable members is usually not such a good idea and has code smell.

I can see why you wanted to implement the Observer/Observable pattern here. If you feel like it, go ahead. But for now the patch is okay as it stands. Thanks for your work!!

Changed in widelands:
status: Confirmed → 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