[Ohrrpgce] Slice based menus

[Jay Tennant]

> From: Ralph Versteegen <teeemcee at gmail.com>
> Sent: Saturday, February 11, 2012 10:07 PM
> 
> On 12 February 2012 06:32, Jay Tennant <hierandel8 at crazyleafgames.com> wrote:
> >> From: Ralph Versteegen <teeemcee at gmail.com>
> >> Sent: Thursday, February 09, 2012 8:58 AM
> >>
> >> 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:
> >
> > I had been working on a new GUI system for this, but I lost steam
> > after demonstrating windowing with button and text controls. The GUI
> > is built similar in design to Window's message queuing, but it is
> > not Windows--the GUI engine I was building was native to C++, and
> > used some of the gfx_* functions to create and render the window
> > rectangles.
> >
> > The reason I stopped was I think there was a memory leak in the
> > GUI manager, but I don't really know how to trace memory leaks
> > well aside from stepping through it.

Come to think of it, I'm not so sure if it was the manager that
was leaking--it may have been some custom windows I had built.

> > But the messages that were processed included:
> > GUI_HITTEST
> > GUI_CREATE
> > GUI_DESTROY
> > GUI_PAINT
> > GUI_MOVE
> > GUI_SIZE
> > GUI_CLIENT_RESIZE (the OS's window client being resized)
> > GUI_FOCUS
> >
> > GUI_MOUSE_OVER
> > GUI_MOUSE_MOVE
> > GUI_MOUSE_HOVER
> > GUI_MOUSE_LBUTTON_DOWN
> > GUI_MOUSE_LBUTTON_UP
> > GUI_MOUSE_LCLICK
> > GUI_MOUSE_RBUTTON_DOWN
> > GUI_MOUSE_RBUTTON_UP
> > GUI_MOUSE_RCLICK
> > GUI_MOUSE_MBUTTON_DOWN
> > GUI_MOUSE_MBUTTON_UP
> > GUI_MOUSE_MCLICK
> > GUI_KEY_DOWN
> > GUI_KEY_UP
> > GUI_KEY_TOUCH
> > GUI_CHAR
> 
> > GUI_IS_MOVABLE_BY_MOUSE
> > GUI_GET_ABS_POSITION
> > GUI_GET_REL_POSITION
> > GUI_GET_SIZE
> > GUI_GET_TEXT
> > GUI_SET_TEXT
> > GUI_GET_ZORDER
> > GUI_SET_ZORDER
> > GUI_GET_TREEDEPTH
> > GUI_GET_CHILDCOUNT
> > GUI_GET_CHILD
> > GUI_GET_PARENT
> > GUI_COMMAND (where this had control-specific commands/notifications, like button being pressed)
> 
> I don't understand what any of these messages are for.

They function very similarly to Window's message handling. For example, upon
window/control creation, the WM_CREATE message is sent to that window's procedure.
In this system, GUI_CREATE is sent to the control's procedure. It's one of the
tenets of window's programming. Is that what you were asking?

> > There was a default procedure for all these messages. Is this the direction you
> > were thinking? Is this useful to the engine? I mean, it doesn't have to
> > be used.
> 
> The slice based menus I was describing were mainly intended for
> in-game, but I'd also want features like mouse support throughout
> Custom, perhaps by splitting that functionality into a separate module
> somehow, or probably just by making all menus in Custom secretly slice
> based under the hood so the code can be shared. I've been working
> towards that already.

That sounds great. Side point, are the slices organized like a document?

> Here's where I see see any GUI framework as possibly fitting in ("C++
> GUI"), as an alternative to other stuff:
> 
> 
>                          GUI                            |  "Application"
> ---------------+---------------+------------------------+--------------------
>                |               | Basic                  |
>    Display     |  Rendering    | user input             |  Specialised user
>                |               | (eg. selecting with    |  input/top level
>                |               |  mouse, arrow keys)    |
> 
> +-----------------------------------------------------+   +------------------+
> |              Other GUI system                       |---> editedit runner  |
> |              (eg. GTK+ based or native)             |   | rewrite, eg.     |
> |                            +------------------------+   | Python + PyGTK   |
> |                            |                            +------------------+
> +----------------------------+--->--------------------+
>                                  |                    |   +------------------+
> +------------+   +-----------+   | C++ GUI            |   | editedit runner, |
> |            |---> C++ GUI   |---> messaging/control  |---> other GUI users  |
> |            |   | rendering |   |                    |   | like map editor, |
> |  Graphics  |   +-----------+   +--------------------+   | sprite editor    |
> |  Backend   |                                            |                  |
> |            |   +-----------+   +--------------------+--->------------------+
> |            |---> Slices    |---> Slice-based        |
> |            |   |           |   | menu system        |   +------------------+
> +------------+   +-----------+   +--------------------+---> Game, plain      |
>                                                           | menus            |
>                                                           +------------------+ 

That is an amazing ascii table! How did you do that? Draw out the whole thing?
(Seems too perfect for that...)

I am in full agreement. I drew up a chart that describes the pieces
fitting together:
http://www.crazyleafgames.com/OutSourced/ohr_gui1.png

The message transport from the backend to the engine would be one of the
input or window messages (ie. GUI_KEY_DOWN, GUI_DESTROY, GUI_FOCUS).
If the backend doesn't support events, then the input state could be
polled, and the GUI manager then generates the events.

The GUI manager requests slices for each window/control created. The GUI_PAINT
message had been issuing from the GUI manager previously. Does the slice
manager handle rendering? If so, GUI_PAINT is pointless now.

GUI manager issues GUI_MOUSE_OVER messages to all windows/controls, and
GUI_KEY_*, GUI_MOUSE_*, GUI_CHAR messages to the focus windows/controls.