[Ohrrpgce] Textboxes and menus

[Ralph Versteegen]

On 5 June 2017 at 05:57, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> 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.
>

Hmm. It makes sense that whatever has focus is on top (though I'm a big fan
of focus-follows-mouse :). And you would always override it anyway.

If a menu or textbox is opened without taking focus, then the textbox/menu
that opened it needs a way to close it when it closes. Menus can already
close textboxes but not the other way around.

Thinking about the most common case, a textbox with a menu instead of a
choice box, would be helpful. Of course that's another feature. (Should we
turn choiceboxes into menus? Or put a simplified menu editor in the textbox
editor (meaning it doesn't create a new menu ID in the menu editor, but
does create a MenuDef when you load it)? Or just add a shortcut for
creating a new normal menu and linking it to the textbox?)

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.
>

I think it's used that way in Entrepreneur; or were all those displays
slices only?


> 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.
>

Maybe it's difficult to come up with a situation where it would be
*needed*, but aren't there a number of RPGs that show two textboxes at
once? Just don't ask me to name any... I can't remember playing any.
It's hard to see how that would actually work, though.


>
>
>> (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.
>

Also, I suggest we make suspendboxadvance suspend choicebox controls too.
They're useless when you can't hit enter, unless you use a script to
advance the box instead, but that would be really weird...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170606/d96dd323/attachment.htm>