[Ohrrpgce] Textboxes and menus

[James Paige]

On Sat, Jun 3, 2017 at 8:28 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:

> Showing a textbox and a menu at once is wonky, and I didn't understand at
> all how it worked until spending 20 min reading the source, so I think it's
> safe to say tahat very few people do.
> Keypresses only affect the top-most menu, but they generally are also
> interpreted by the textbox, except the textbox is not affected if the menu
> suspends gameplay.
> (Interestingly, opening a menu is the only way to suspend choicebox cursor
> controls)
>
> So, if not suspending gameplay, pressing enter will cause both the textbox
> to close and the menu to activate... unless the selected menu item is one
> of the builtin menus, in which case the enter keypress will be cleared when
> leaving the menu, so that the textbox doesn't close.
>
> Even worse, when showing a textbox with a choice box at the same time as a
> menu the arrows keys affect both of them! This clearly should be fixed, but
> I think the Enter behaviour is bad too.
>
> Currently you can give the menu sole focus by setting it to suspend
> gameplay, and you can give the textbox focus by setting "No player control
> of menu", although then you need to use a script to close the menu.
>
> Clearly to change anything we need a backcompat bit, but it's not easy to
> see what to change to. I want to simplify, not make it make complicated.
> I think we need to track whether the textbox or the menu has focus
> (whichever was opened last), and maybe even (virtually) put the textbox in
> the menu stack.
> So if a menu is opened from a textbox, or a textbox from a menu, then it
> takes focus; but we also will want a way to override that; maybe the 'No
> controls' menu bit can be repurposed.
>

I agree, the current behavior is a mess, and anything it does now is just
implementation quirks, not planned or desired behavior.

I love the idea of menus or textboxes having focus. Now that you mention
it, one of my forgotten plans as part of converting things to slices was to
allow the text box layer and the menu layer to change their order so either
one could be on top.

If I remember correctly, my original intention for the "No player control
of menus" was a somewhat ill-conceived pre-slice idea bout using menus as
informational displays while the player was still waking around and acting
normally. I don't know if anybody ever use that bit that way or not.



> Also, maybe we should think ahead to the possible ability to have mutliple
> textboxes open at once, on a stack.
>

That could be useful, but lets not worry about it too much until somebody
has a game idea that needs it.


> (I also think it's strange that ESC doesn't advance textbox, so would like
> to add a backcompat or pref bitset for that.)
>
>
That sounds reasonable to me :)

I don't remember why I excluded ESC from doing that in the first place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170604/fc907f1a/attachment.htm>