[Ohrrpgce] Slice based menus
Ralph Versteegen
teeemcee at gmail.com
Sat Feb 11 20:07:04 PST 2012
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.
>
> 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.
> 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.
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 |
+------------------+
More information about the Ohrrpgce
mailing list