[Ohrrpgce] Slice based menus

[Ralph Versteegen]

On 14 February 2012 04:28, James Paige <Bob at hamsterrepublic.com> wrote:
> I think that slice collections are already very close to being able to
> do everything we need for special screen layouts.
>
> The fundamental feature of menu items that sets them apart from any
> slices we have right now is the fact that menus need to have a concept
> of keyboard-focus, and they need a way of knowing how they are connected
> by arrow key movements. (btw. I believe this was the main intent of the
> original "slices" from the ohrrpgce-fmf implementation that inspired the
> ohrrpgce's slice system in the first place)
>
> The GridSlice can already do a good job of arranging menu items into
> menu-like shapes.
>
> Complex menu items, like in the Save menu or the Load menu can be
> separate slice templates. Or to explain that another way, the save menu
> could use two templates. One for the save screen, and one repeated for
> each save game slot.
>
> What we are really missing is features for controlling keyboard focus.
>
> (James commences thinking-while-typing)
>
> Suppose every slice has the ability to be focused, although all slices
> are non-focusing by default.
>
> If I was creating the Save menu, I would mark the save slots as
> focusable... I mean in the layout template for the whole save screen.
> Nothing in the slice layout for individual save slots would need to be
> focusable.
>
> Focus needs to be displayable somehow. This is the same as the selected
> and unselected animations you were talking about.
>
> A selected and an unslected mode for a slice is more or less the same
> thing as bifurcating all the slice's visual properties.
>
> Imagine if a SelectableSlice was a special type of container slice that
> has two children. The first one is displayed when it is unselected. When
> it becomes selected, the first child becomes hidden, and the second
> child becomes visible.
>
> A SelectableSlice could also contain the properties that describe how
> keyboard focus changes. We could certainly have a simple spatial
> heuristic that would make a good default. Press the left arrow, and move
> the focus to the next slice with a smaller X position. Or maybe a
> smaller X center.
>
> We could also have focus handlers like: press the up arrow and move
> focus to the first selectable ancestor. or press the down arrow to move
> to the first selectable child. We could also have handler that would
> jump to a specific other slice by lookup code in response to a key.
>
> Besides directional arrow keys, we could also have handlers for Confirm
> and Cancel.
>
> I probably shouldn't be using the world handlers here, because that
> sounds like a script thing. Maybe I should call them focus-actions, ...
> although triggering a plotscript would be a great focus-action.
>
> Does any of this make sense? Does any of it jive with what you are
> thinking about this issue?
>
> I looked at all those screenshots that you mentioned, and I think that a
> SelectableSlice could handle all those situations without too much
> trouble.
>
> ---
> James

At first this sounded orthogonal to what I was talking about, but then
I thought it seems a bit incompatible, since you seem to be talking
about SelectableSlices handling input themselves, without an explicit
menu anywhere, but after another reread, it seems like you might be
talking only about replacements for the builtin menus, completely
separately to usemenu- or MenuDef-based menus.

I'm not sure that I'm keen on the focus handlers, though, because it
sounds like it's doing away with having a menu object (by which I
guess I mean MenuState), which is probably the idea. But without a
menu object, how do you get things like page up/down, scrolling, and
activing or deactivating a whole menu?

SelectableSlices could work, but sounds like unnecessary complexity
and something that should be abstracted a little: if you have a simple
textual menu item, then having to modify both children when you want
to do something like add an icon on the fly with a script sounds bad.
Rather, we could use the two-children-one-hidden system for maximum
flexibility, and something simpler the rest of the time: change the
appearance of your children whenever your focus changes. Have some
functions/script commands to abstract the difference.

To facilitate that, an idea I just had is adding "compound UI colours"
(or "menu UI colours"). Each such compound colour (which preferably
would have a single UI colour number from the point of view of user,
though I guess it would be multiple uicolor() entries) would consist
of the following:
-normal
-selected (2 (or more?) colours)
-disabled
-disabled selected (multiple)
If you set a text slice to a normal (master palette) entry, or a
regular UI colour, it wouldn't animate when selected, but if set to a
compound, then the display colour could automatically adjust if used
anywhere inside a SelectableSlice/MenuItemSlice (are these the same,
or do disabled colours only make sense in the later?)

You might remember that I suggested some "texttags" (markup) that
would cause the text colour to toggle or shift randomly. That could be
based on compound ui colours too.

Getting back to "simpler" SelectableSlices, the only thing that would
change automatically would be the display colours of anything using
compound ui colours.

> On Fri, Feb 10, 2012 at 03:57:59AM +1300, Ralph Versteegen wrote:
>> I've been struggling to decide how slice based menus should work, so I
>> need some input. I've been thinking about it for years, but could
>> never decide where to start (writing this helped a lot though).
>>
>> This isn't about making menus draw themselves using slices, but to
>> allow more complicated menus, like some of the features in these
>> examples:
>> * Our existing items/spells menus. (In future, it would be nice if the
>> item and spell-list menus were slice-menu-based.) That means allowing
>> 'empty' menu items too. I'm including the Desciption line at the
>> bottom; to support that (generically), you need to be able to edit a
>> slice collection for the editor, and tag slices (lookup codes?) to
>> show data on the currently selected menu item. I imagine that such
>> menus should have "types" (eg. items, heroes, spells), and contain
>> menu items which are of the correct type (or "typeless" like our
>> current ones)
>> * Our existing save/load menu. After all those wonderful animation
>> features are implemented, we could allow creating "selected" and
>> "unselected" animations on sprites... but defining a "selected"
>> animation on a hero battle sprite which is used only in the save menu
>> is just too obscure.
>> * http://rpgmaker.net/media/content/users/45/locker/MenuWIPX.png
>>   (This seems to the standard RPG Maker VX menu, themed a bit) --
>> notice the 'cursor' is a highlighting rectangle behind the menu item.
>> That type of cursor will be tricky to implement if menu items can be
>> variable size, and if it should move smoothly between items.
>> * Everything on this page:
>> http://www.rpgmpavilion.com/index.php?page=rpgtdseditor
>>   Things can change colour or image when you select them; the cursor
>> can be both a litle hand icon and an outline rect; paginated menus
>> (next/prev page icons/buttons)
>> * http://www.mobygames.com/game/iphone/doom-ii-rpg/screenshots/gameShotId,430863/
>>   (The OTHER Doom RPG) Custom scroll bar, mouse support. (Guess the
>> background could easily be part of it too)
>> * http://www.roc.noaa.gov/WSR88D/Operations/EPSS_B10/rpg_epss/selectable_parameters/rpg_products_window.png
>>   Menu items (unselectables here) which look totally different. Yes I
>> know that's a completely different type of menu.
>>
>> I don't want to spend a lot of work on something that's overly complex
>> and won't be used. Both static menus created entirely in the editor,
>> and what can be done with scripted menus should be improved. However
>> complex features which are only useful in combination with scripts,
>> and which don't save much work over scripting from scratch should be
>> avoided. (I seem to be bad at determining this cutoff.) So here are
>> the ideas I wanted to bounce.
>>
>> I see a lot of patterns in the above examples. Focusing on just some
>> of the features for now, I suggest that for each menu should have two
>> editable slice collections: the menu itself (background/rect,
>> scrollbar, things like a 'Description' line, additional decoration),
>> and a menu item template slice collection. The thing is, without
>> scripting, the only variable part of the template would be (I imagine)
>> the text slice inside it flagged with the 'caption' lookup code.
>> (Maybe lookup codes are too restrictive for flagging slices for this
>> purpose.) To allow more variability, we need one of:
>> * add more properties to (all) menu items, like "icon", "description".
>> I guess extra data could also be used, but how exactly are you meant
>> to apply an integer to an arbitrary slice type?
>> * "typed" menus, as I mentioned before. Then we can have lots of
>> type-specific flags (lookup codes), like "item value" and "text
>> describing who can equip item"
>> * some way to define new menu item properties specific to a single
>> menu (using slice lookup codes to flag wouldn't work so well, they
>> would have to be dynamically allocated)
>>
>> Also, these lookup codes could be applied to slices in the menu slice
>> collection and be set using the selected item (such as for a
>> 'Description' line).
>>
>> If menu data was RELOAD-based, it would be easy to just store slice
>> collections inside the menu data; unfortunately they aren't. So I
>> guess they'll go in separate slice collection collections.
>>
>> Being able to edit menu's slice collection is a big problem, because
>> this duplicates a lot of existing options, such as menu size and
>> placement and box visibility and text alignment, in much more
>> complicated ways. And once you edit the slice collections manually,
>> your changes won't necessarily be mappable back to the existing
>> options. So maybe we would need to make these two editing methods
>> mutually exclusive. This sounds like additional complexity and
>> confusion though.
>>
>> Cursors could be implemented as a third slice collection, allowing
>> lots of flexibility, but I won't get into that.
>>
>> On to some implementation details. Currently my idea is three new
>> types of slices:
>> - MenuSlice
>>   Top level slice. Just a container, eg. for the menu items container,
>> background box if any, etc. Associated with a menu (freeing it would
>> close the menu; have script command to get the menu handle), but
>> probably nothing else special about it.
>> - ItemLayoutSlice
>>   A container to which all the menu items are parented. Freeing
>> directly not allowed. Similar to a GridSlice, but we need more
>> flexibility, especially menu items with variable heights. In
>> particular, we need a type of container which resizes itself to
>> contain all of its children, rather than the other way around. This
>> would be independently useful for users, as an alternative to
>> GridSlices.
>> - MenuItemSlice
>>   Also a container. Associated with a menu and menuitem (freeing would
>> delete the menu item; allow reordering menu items too?).
>> _______________________________________________
>> 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