Opened 6 months ago

Last modified 2 months ago

#5369 new defect

JSInterface GUIPage - Allow parent GUI page to update a child GUI page

Reported by: elexis Owned by:
Priority: Should Have Milestone: Backlog
Component: Core engine Keywords:
Cc: Patch:

Description

In some cases, a GUI page opens a child GUI page, and the information on that child page has to be updated if an event in the parent GUI page was handled.

For example in r18078 / Phab:rP18078#inline-2604 added that the AI configuration dialog is updated with the new settings if the host has changed the settings.

Another example would be the network window #3787 that has to be updated whenever g_GameAttributes or g_PlayerAssignments changes.

Closing the dialog, assembling the last user selection and choices, passing that to the parent page and opening a new dialog with the new data and the old settings seems like a workaround. The existing window should be updated instead of closed and reopened. (It could even be visible to the user if the renderer would render independently).

This way, the child GUI page could keep it's data localized, rather than "poisoning" the parent GUI page with information it ought to be agnostic of.

A third example could be the session dialogs (for example diplomacy dialog). They are currently implemented as a GUIObject rather than a GUIPage (this pattern is not possible for every dialog, as for example the network dialog should be openable from multiple pages).

var g_ChildPage = Engine.PushGuiPage(oldData);
g_ChildPage.updateSomething(newData);

Change History (2)

comment:1 Changed 6 months ago by elexis

Preliminaries:

Took a solid week to remove this JS workaround, but I think the code is much cleaner and extensible afterwards.

Last edited 6 months ago by elexis (previous) (diff)

comment:2 Changed 2 months ago by wraitii

In 22200:

Remove workaround in GetGUIObjectByName

rP7214 added a problem: Engine.GetGuiObjectByName? is unaware of the caller GUI page.
So GUI pages in the background that still run the onTick and other event code tried to look on the topmost GUI page, rather than their own GUI page.
rP7769 added a workaround that has to be copied to any place that can call JS code.
If developers don't know about the reason for this workaround and add a new place that can call JS code (#5369), they won't be able to implement anything.

This removes this workaround by passing the pointer to the correct GUI page as callback data.

Patch By: elexis

Reviewed By: wraitii

Refs #5369

Trac Tickets: #5369

Differential Revision: https://code.wildfiregames.com/D1701

Note: See TracTickets for help on using tickets.