Opened 12 months ago

Last modified 4 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 (4)

comment:1 Changed 12 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 12 months ago by elexis (previous) (diff)

comment:2 Changed 8 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

comment:3 Changed 5 months ago by elexis

In 22530:

Delete unused broken JSI_IGUIObject::construct.

The constructor is invalid, because one cannot create or obtain and pass an IGUIObject C++ class instance pointer via JS, only triggering a crash when doing something with it.
If there was a use case, the GUIObject should be created with a GUIObject type specific constructor.
Remove obsolete getProperty comments.

From D1699, refs #5369 and wraitiis equivalent:
Differential Revision: https://code.wildfiregames.com/D1933

comment:4 Changed 4 months ago by elexis

In r22588:
Move CGUIManager::LoadPage to CGUIManager::SGUIPage::LoadPage, because it only operates only on that struct.
Refs Phab:D1684 (patch also made an appearance in Phab:D2108)

Note: See TracTickets for help on using tickets.