HomeWildfire Games

Add buttons for changing between, and hotkeys for opening, the civinfo and…


Add buttons for changing between, and hotkeys for opening, the civinfo and structree

Patch by: fpre
Reviewed By: s0600204
Fixes: #4970
Differential Revision: https://code.wildfiregames.com/D846

Event Timeline

ffffffff raised a concern with this commit.Feb 25 2018, 11:14 PM
ffffffff added a subscriber: ffffffff.
ffffffff added inline comments.

"Alt+Shift+S" is a doubled hotkey at the moment (same as structure tree (structree)). So on hit it opens structure tree and toggles silhouttes, which is not a good behaviour.

So I guess we can just take "Alt+S" as its at the moment only assigned to next tab hotkey (hotkey.tab.next) but it is not used in the session gui,
it is only used in the options and summary gui, that can be toggled by the session's menu but it is a new gui, so it doesn't interfere with the session.

"Alt+S" is also a good hotkey because the Diplomacy Toggle Hotkey is also "Alt+X" and both effecting the silhouttes.

This commit now has outstanding concerns.Feb 25 2018, 11:14 PM
s0600204 added inline comments.Mar 2 2018, 1:58 AM

How about "Alt+Shift+T"? (For the structree) Not used by anything currently as far as I can see...

ffffffff added inline comments.Mar 2 2018, 3:58 AM

Maybe "Alt+Shift+R" ? Not so far for the fingers ..

Or we change

scroll.speed.decrease from "Ctrl+Shift+S" to "Ctrl+Alt+Shift+S"

and silhouettes to "Ctrl+Shift+S"

Then structure tree hotkey is still one hand grabable (at last for me x) )

Actually the best way would be for me "Alt+S" but bb made that key for tab forward

s0600204 added inline comments.Mar 2 2018, 6:00 PM

I'd personally favour a solution where we didn't have to reassign other hotkeys.

The reason I suggested "Alt+Shift+T" was that the letter choice made some sense on some level ("T" for "tree"). (And FWIW it is attainable with one hand for me, although I am aware that some players may not be as dexterous.)

Of course, there's no reason why there has to be a hotkey - the structree is not an essential gameplay mechanic.

ffffffff added inline comments.Mar 5 2018, 4:19 PM


vladislavbelov added a subscriber: vladislavbelov.EditedApr 7 2018, 2:03 AM

Any progress with the hotkey?

@ffffffff @s0600204

s0600204 requested verification of this commit.Apr 9 2018, 5:21 PM

All sufficiently happy?

This commit now requires verification by auditors.Apr 9 2018, 5:21 PM
All concerns with this commit have now been addressed.Apr 11 2018, 11:54 PM
elexis added a subscriber: elexis.Sep 10 2018, 5:22 PM
elexis added inline comments.

This function should remain agnostic of any content. Moving to g_MiscControls from D322.


Moving to g_MiscControls too

elexis added inline comments.Nov 29 2018, 2:35 PM

As far as I understand the PushGuiPage function introduced in rP14496, the callback argument of PushGuiPage means that the given function is called after the GUI page to be opened is closed; i.e. it not being optional for the page to call the callback function.

I see this belief manifested in msgbox.js, summary.js, civinfo.js, manual.js, options.js, core.js, structree.js where we find this pattern:

			if (data.callback)

But here the callback is skipped because that happens to fit the pause/resume necessity.

Having the child GUI page able to decide to skip the parent GUI pages callback handler means that the parent GUI page has no chance of being certain that the callback function is called regardless of what the child GUI page computes.
Always executing the caller would also mean one could unify PopGuiPage and PopGuiPageCB, merge all above cases, but also has to remove the pop call from this switchToStrucTreePage function and add the push call to the mainmenu, gamesetup and session gui page...

Merging the structree and civinfo page would prevent the problem but not solve it.
So it seems like undesirable code but unsolveable if one wants to keep the feature.


This page is inconsistent:

  • session persists civ
  • gamesetup.xml persists civ
  • mainmenu.xml does not persist civ

A proponent of civ persistance might propone civ persistance when switching from gamesetup to session.
An opponent of civ persistance that argues based on undesirable code traits might oppose civ persistance in the other two pages too, as they add the same code traits.


Missing pauseGame(); and closeOpenDialogs(); calls if we look at menu.js.


Code seems ugly (1) but unimproveable (2):

  1. Duplication and mixing of concerns: The global g_CivInfo and these callback functions storeCivInfoPage are undesirable code traits, because:

    1.1. Mixing of concerns: GUI pages ideally remain unaware of the state of other GUI pages, so that other GUI pages can be worked on individually. See for example https://en.wikipedia.org/wiki/Single_responsibility_principle and https://en.wikipedia.org/wiki/Separation_of_concerns The menu, gamesetup and session should not have to hardcode the most recent features of the civinfo and structree code.

    1.2. Duplication: Storing this in the caller GUI page means having to copy the state variable and callback function to every GUI caller (that's 2 or 3 pages for now but maybe extended in the future), making it timeconsuming to maintain and more prone to coding errors. (I run into this effect for example when changing the GUI Push/PopGuiPage callback handling from rP14496, but the problem is systematic)
  1. However I don't see an alternative other than:
    • using the Config system (regardless whether its written to the disk or not).
    • hiding the page instead of closing it, so that the page doesn't lose it's state, keeps all state as local as possible and GUI pages remain agnostic of each other

This page inconsistent:

  • mainmenu has a button for structree and a button for civinfo
  • gamesetup has a button that opens civinfo (or structree if the user had switched the page after opening it)
  • session has a button that opens structree (or civinfo if the user had switched the page after opening it)

It might be less confusing to the user, reader, maintainer, extender and UI designer if the button works on all pages the same way.