[Ohrrpgce] Textboxes and menus

Thu Jun 8 09:09:42 PDT 2017

On Thu, Jun 8, 2017 at 8:56 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 7 June 2017 at 05:49, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> 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.
>>
>
> I was imagining that the better interoperability would include an upgraded
> choicebox editor which is either the real menu editor, or a simplified
> version. But I guess keeping around an obsolete choicebox system instead of
> replacing it is simpler in several ways than getting choiceboxes and menus
> to behave identically, even if it means having a second system around.
> (There could be a per-textbox option between 'basic choicebox' and 'menu')
>
> Conceivably, we could even add the menu-integration first, and in future
> add an upgrade routine which turns choiceboxes to new-style menus (which
> might not initially be possible due to missing bitsets). This makes me much
> more comfortable about actually starting on it!
>
>
That sounds good! I like that!

> (Another problem is that choiceboxes are slice-based, and therefore can be
> manipulated with scripts)
>

I wonder if anybody has done it?

Checking definitively seems impossible, but checking if anybody has ever
used the choicebox's slice lookup codes have ever been used might be
plausible.

That is indeed a downside of converting things into slices. Backwards
compatible changes to sliceified GUI is dang hard to do.

>
>
>>
>>
>>>
>>>>
>>>>> 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.
>>
>
> A command to copy a slice subtree would be useful in general. It would
> have to either remove protection flags and special lookup codes, or fail.
> (It would still have to fail regardless when copying special slice types,
> or maybe turn them into container slices.)
>
>

>>
>>>
>>>> ... we might want a command that just loads a textbox as a slice,
>>>> without triggering any of the apparatus of textbox chaining and
>>>> conditionals.
>>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170608/f6f1b205/attachment-0001.htm>