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 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@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
