Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confirmation (Yes/No/OK/Quit/Logout) Overhaul #884

Merged
merged 6 commits into from
Jun 16, 2021

Conversation

Hoikas
Copy link
Member

@Hoikas Hoikas commented Mar 20, 2021

While working on the clickable links in KI Chat concept, it became apparent that I needed to issue a confirmation or Yes/No dialog from a Python script that did not have its own plKey. Currently, Yes/No dialogs are handled by the xKI python scripts over many hundreds of lines in an especially ad-hoc way and can only be responded to using a plNotifyMsg. This implements a singleton whose job is to receive confirmation requests from anyone who links against plMessage and respond to them via either a (potentially stateful) lambda or using a legacy plNotifyMsg.

This new functionality will allow us to be very flexible with where we issue and how we respond to confirmation requests. Some examples floating around in my mind:

  • PtYesNoDialog() can accept a Python callable to call back in addition to a key to notify.
  • If linking to an Age fails, we can ask if we want to quit or return to the previous Age... instead of popping up an OS dialog that says "Link to Age failed"
  • Localized dialogs can be issued from code in C++ that does not link against pfLocalizationMgr.

@dpogue
Copy link
Member

dpogue commented Mar 20, 2021

The implementation and overall design looks good to me.

Do we want this as a new fixed key singleton, or could we use pfGameGUIMgr as the receiver of plConfirmationMsg, and have it own a plConfirmationMgr that it passes them to?

Putting this in pfCharacter seems a bit weird, but pfCharacter is already a bit weird... 🤷🏼‍♂️

@Hoikas
Copy link
Member Author

Hoikas commented Mar 21, 2021

I considered putting this into the pfGameGUIMgr target, but I felt like pfCharacter was more appropriate, since that used to house player interface elements many moons ago. I didn't really consider adding it directly to pfGameGUIMgr the class because everything is terrible over there. 😞

@Hoikas
Copy link
Member Author

Hoikas commented Mar 22, 2021

I've adding the Python bindings for plConfirmationMgr. To ease porting, I kept the name PtYesNoDialog and its argument signature largely unchanged to ease porting.

if (pyKey::Check(cbObj)) {
cb = pyKey::ConvertFrom(cbObj)->getKey();
} else if (PyCallable_Check(cbObj)) {
cb = plPythonCallable::BuildCallback<plConfirmationMsg::Result>("PtYesNoDialog", cbObj);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zrax I'm a little unhappy that this function requires manual specification of the callback arguments. I'm sure there's a way to erase those, but I'm drawing a blank. Any ideas?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can in this case, at least not without moving the construction of the tuple outside the callback...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got it down to specifying the variant index, which is good enough... I guess...

@Hoikas Hoikas marked this pull request as ready for review March 25, 2021 17:43
@Hoikas Hoikas changed the title WIP: Confirmation (Yes/No/OK/Quit/Logout) Overhaul Confirmation (Yes/No/OK/Quit/Logout) Overhaul Mar 25, 2021
@Hoikas
Copy link
Member Author

Hoikas commented Mar 25, 2021

We're ready for more detailed review 🚀

@DurinMephit
Copy link
Contributor

One of my grievances with the old Logout dialog is that it is not keyboard-accessible. A good UI should let a person tab between the buttons, with some indication of which is selected, and ENTER or SPACE or something like that should trigger the button.

Should I get my hopes up that this might be addressed with this overhaul? :)

@dpogue
Copy link
Member

dpogue commented Apr 2, 2021

Should I get my hopes up that this might be addressed with this overhaul?

That's probably a task for a separate round of changes, since it probably involves adding a concept of "focus" to the GUIDialog control classes and potentially changes to the art asset files.

Accessibility is important though, and thanks for raising this. Reporting a new issue is probably the best way to keep it from getting lost.

pfConfirmationMgr is designed to replace the ad-hoc Yes/No dialog
implementation in xKI. Currently, the KI handles throwing up its own
dialogs and can respond to pfKIMsgs sent with a kYesNo type. The result
is the handling of confirmation dialogs is:

- Dependent on having a functioning KI python.
- Spread over many hundreds of lines of python.
- Requires having a plKey to receive a response.

These limitations make doing things that require confirmation annoying.
This system will allow you to dispatch a confirmation dialog from
anywhere in the engine that links against plMessage and receive the
results either in a (potentially stateful) lambda or via a legacy
notification message.
This will allow them to be reused more easily.
This also includes the first stab at some general code that allows
firing an arbitrary callback from the engine into Python code without
leaking resources.
This conflicts with what we're doing in pfConfirmationMgr and therefore
*MUST* be replaced in order for everything to work correctly.
Low-hanging fruit and improves our localization coverage.
@Hoikas
Copy link
Member Author

Hoikas commented May 30, 2021

Rebased to merge without conflicts.

@Hoikas Hoikas merged commit f8aaae4 into H-uru:master Jun 16, 2021
@Hoikas Hoikas deleted the better-yesno branch June 16, 2021 14:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants