[Ohrrpgce] Slice based menus

[Jay Tennant]

> From: James Paige <Bob at HamsterRepublic.com>
> Sent: Monday, February 13, 2012 9:48 AM
> 
> One more afterthough on this-- although the SelectableSlice seems like a 
> really obvious and simple feature (to me) for the implementation of 
> customizable special screens, I have no clear idea in my head about how 
> SelectableSlice would work for purely plotscripted slice collections, 
> and I am especially fuzzy about how plotscripted keyboard interaction 
> would work together with SelectedSlice's focus-action handlers for arrow 
> keys and confirm/back keys.
> 
> ---
> James
> 
> On Mon, Feb 13, 2012 at 07:28:33AM -0800, James Paige 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)

I've worked through the focus issue by allowing child controls decide whether
they wish to process a message or pass it to their parent. So a button
could process an Enter keypress message to activate the button. But an
Arrow keypress would be passed to it's parent. The parent can decide how
to treat that keypress, such as by iterating through a group of buttons
(ie. radio button selection).

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

Hmm, that heuristic seems good. And TAB stopping could progress through 
the list of child elements?

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