[Ohrrpgce] Textboxes and menus

[James Paige]

On Mon, Jun 5, 2017 at 7:39 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> 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?)
>
>
Ooh! I love the idea of choiceboxes using a simplified menu editor that
creates a MenuDef without a menu ID.

I *also* like the idea of a shortcut for creating a new menu linked to a
textbox.

I can't decide which is better...


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

I don't remember


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

Seems like a stack of multiple open textboxes would be a bit confusing.

If somebody really needs that, they can already script it pretty
painlessly, just by opening a textbox, grabbing the slice handle, and
re-parenting it to the script layer

... we might want a command that just loads a textbox as a slice, without
triggering any of the apparatus of textbox chaining and conditionals.



>
>
>>
>>
>>> (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...
>
>
Yes, I think forgetting to disable choicebox controls on suspend box
advance should probably be treated like a bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170605/7d2c5048/attachment-0001.htm>