[Ohrrpgce] Textboxes and menus

[James Paige]

On Tue, Jun 6, 2017 at 8:38 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 6 June 2017 at 04:06, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> 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...
>>
>
>
> I like the idea of a simplified menu editor too, but wonder if we'll just
> end up replicating the menu editor. Couldn't the simplified view just be a
> part of the menu editor proper?
> I imagine the simplified view would just:
> -skip the toplevel menu editor menu, since most options aren't really
> needed, or are defined by the textbox
> -default new menu items to Caption type, close if selected (this is a
> reasonable default anyway)
> -have a simpler way to select the effect of each menu item. For example,
> maybe press TAB to switch focus to a small floating side window with just
> 1-2 options. This sort of thing clearly can be added to the menu editor
> proper too... in fact it seems I am talking about the 'proper' menu editor.
>

I like all of that.


> My thoughts are very confused on all of this, but...
> Choiceboxes currently aren't mutually exclusive with opening a new menu
> from the conditionals menu, but it would be horrible to have two different
> ways to open a MenuDef from a texbox. Maybe allow you to either open an
> independent menu (as currently... and keep the option in the
> Conditionals?), or have a menu attached to the box as a choice box, but not
> both.
> Also choiceboxes aren't treated like menus. So does this mean that they
> can't be converted to MenuDefs? And we can't replace the limited
> choiceboxes with MenuDefs, unless we don't put them on the normal menu
> stack? That seems a bit awful.
> But maybe it's alright if the flexible MenuDef replacement for choice
> boxes (whether they get normal menu IDs or not) don't behave like existing
> (backcompat) choiceboxes, but instead are normal menus. This would allow
> the box and menu to close independently unless we force-linked the two. (Eg
> if from the choice-menu you open a submenu, and then advancetextbox gets
> called, both menus and the textbox are closed)
>
>
Thinking about this more, maybe it is a mistake to try and convert
choiceboxes into MenuDef?

Maybe it is better to just improve the interoperability of menus and
textboxes, and add features to the textbox editor to make  it easier to
combine menus with textboxes.

It would not be so bad if Choiceboxes remained a little odd-thing that
textboxes can do for backcompat but that aren't important anymore.





>
>>
>>> 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.
>>
>
> I guess it's quite unimportant.
> But I think I see how I would implement it: rather than a stack of
> textboxes (which would imply that some of the on-close actions of the
> others haven't happened yet), just add a 'keep previous textbox visible'
> bit to a textbox to keep the old text slices. So a limit of two textboxes
> displayed at once. The main use of the feature would be to display a
> conversation between two characters.
>
>
>>
>> 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
>>
>
> I don't think you can do that, because it's protected.
>

Maybe not. I guess we probably do need a command to load a textbox as a
slice... either that or a command that can make an unprotected clone of a
protected slice.


>
>> ... we might want a command that just loads a textbox as a slice, without
>> triggering any of the apparatus of textbox chaining and conditionals.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170606/d8e91656/attachment.htm>