Re: [Ohrrpgce] Slice based menus
On 22 February 2012 07:32, Mike Caron caron.m...@gmail.com wrote: On 2012-02-21, at 12:36 PM, James Paige b...@hamsterrepublic.com wrote: On Tue, Feb 21, 2012 at 07:47:06PM +1300, Ralph Versteegen wrote: On 21 February 2012 06:46, Jay Tennant hierand...@crazyleafgames.com wrote: From: James Paige b...@hamsterrepublic.com Sent: Monday, February 20, 2012 10:00 AM I have been reading this whole thread, and I have to admit, I am totally confused. I am not sure at all what you are working on. Would you mind explaining this project to me? --- James Of course. I'll explain the problem, goal, and implementation of this project. I'll chip in as well... 1. Problem: the OHRRPGCE GUI lacks a uniform implementation I like the OHRRPGCE's interface, but it is difficult to upgrade it to be point-and-clickable. Additional monitoring would be necessary to capture the mouse coordinates and button presses. While that can be done for one menu, the lack of uniform implementation makes it troubling to monitor each menu. And if there was interest to adding more buttons later on, understanding context and rewriting the monitoring code could become daunting. It would be easier if the menu items were objects that could respond to operations performed on them--encapsulation. It would be easier if all menu objects interfaced the same way. It would be easier if there was a manager that uniformly passed messages to the appropriate menu objects that are the focus of the user's input. 2. Goal: create a GUI system that brings uniformity and flexibility to the rendering, interfacing, and management of menu's in the engine. This is for the graphical menus in Custom, of which there aren't many currently: font, sprite, tile, and map editors. The others are just lists of menu items and aren't included in this. The map and sprite editors have lots of different widgets visible onscreen, and the code for them is a mess because we have these monolithic functions that handle everything instead of splitting things up. The map editor and sprite editor code is terrible because it is some of the oldest code in the engine, and because I knew nothing about good design when I wrote it :) There is nothing inherently difficult about creating a complex irregular screen layout that prevents the code from being well organized-- it just doesn't happen to be that way right now :) I love the idea of being able to add callbacks to slices. Consider the sprite editor. I like the idea of having button slices that run a callback if you click on them. They could also have a key shortcut callback so that the existing keyboard shortcuts for them could continue to work. I also like the idea of mouse-down and mouse-up callbacks for the sprite drawing area. I was originally thinking that we would just use a slice to specify the position where the drawing area is located on the screen, and hand-code the rest, but it would be much better if the slice could recieve mouse and keyboard events and pass them on to appropriate sprite-drawing handlers. This is a non-OS specific goal. Everything is rendered inside the engine, as it is now. The objective is to make widgets that are intuitive for users. It is a native implementation. native implementation? What does native mean anyway? I always thought it meant provided by/tightly dependent on the platform (OS/hardware). There was also another goal: look into whether it would be possible to abstract different GUI frameworks. Maybe we could draw widgets using either slices, or something like wxWidgets (which I was especially interested in, due to my gfx_wx attempt) A GUI manager can create, destroy, and pass messages to widgets. A widget can optionally process the messages, or delegate the message processing to another widget. All widgets have a message procedure. Functionally, this is very similar to Window's design. Messages generated by the GUI manager are added to a queue, then processed in the order they are added. Why queue messages instead of dispatching them immediately? So that widgets can peek ahead? 3. Implementation: GuiManager, GuiObject, GUI_* messages, input synthesis, and rendering I've already been working on this since October of last year, though I stopped somewhere in late December (work, etc.). I developed a GuiManager object, which provides methods for sending and posting messages, changing focus, and synthesizing input to appropriate GuiObject's. A GuiObject is an implementation of a widget. I successfully created a Button and Text widget, and a custom widget to test the button and text on. Jay mentioned that he was working on a GUI framework written in C++; not directly OHR-related at the time, but I believe built on gfx_directx? I said that the OHR needed such a thing to clean up the map and sprite editors, so I'd like to see whether we could reuse any of his code. Jay's uses message passing
Re: [Ohrrpgce] Slice based menus
From: Ralph Versteegen teeem...@gmail.com Sent: Tuesday, February 21, 2012 12:47 AM On 21 February 2012 06:46, Jay Tennant hierand...@crazyleafgames.com wrote: From: James Paige b...@hamsterrepublic.com Sent: Monday, February 20, 2012 10:00 AM I have been reading this whole thread, and I have to admit, I am totally confused. I am not sure at all what you are working on. Would you mind explaining this project to me? --- James Of course. I'll explain the problem, goal, and implementation of this project. I'll chip in as well... 1. Problem: the OHRRPGCE GUI lacks a uniform implementation I like the OHRRPGCE's interface, but it is difficult to upgrade it to be point-and-clickable. Additional monitoring would be necessary to capture the mouse coordinates and button presses. While that can be done for one menu, the lack of uniform implementation makes it troubling to monitor each menu. And if there was interest to adding more buttons later on, understanding context and rewriting the monitoring code could become daunting. It would be easier if the menu items were objects that could respond to operations performed on them--encapsulation. It would be easier if all menu objects interfaced the same way. It would be easier if there was a manager that uniformly passed messages to the appropriate menu objects that are the focus of the user's input. 2. Goal: create a GUI system that brings uniformity and flexibility to the rendering, interfacing, and management of menu's in the engine. This is for the graphical menus in Custom, of which there aren't many currently: font, sprite, tile, and map editors. The others are just lists of menu items and aren't included in this. The map and sprite editors have lots of different widgets visible onscreen, and the code for them is a mess because we have these monolithic functions that handle everything instead of splitting things up. This is a non-OS specific goal. Everything is rendered inside the engine, as it is now. The objective is to make widgets that are intuitive for users. It is a native implementation. native implementation? What does native mean anyway? I always thought it meant provided by/tightly dependent on the platform (OS/hardware). Provided by/tightly platform dependent? Eh, no. Here's a picture: http://www.crazyleafgames.com/OutSourced/widgetExample1.png I left the rest of the screen on to emphasize there aren't any other windows. Those slices of graphical rendering are done in the program, not drawn by Windows, or some platform library. At the time, I was using vertex and index buffers to render these, but we won't be doing such for the GUI objects this time, rather using gfx_surfaceCopy or slices, or something. The mouse was hovering over the top button, whereas the other buttons were plain. I don't have the images of the other experiments I ran with the GUI system. There was also another goal: look into whether it would be possible to abstract different GUI frameworks. Maybe we could draw widgets using either slices, or something like wxWidgets (which I was especially interested in, due to my gfx_wx attempt) A GUI manager can create, destroy, and pass messages to widgets. A widget can optionally process the messages, or delegate the message processing to another widget. All widgets have a message procedure. Functionally, this is very similar to Window's design. Messages generated by the GUI manager are added to a queue, then processed in the order they are added. Why queue messages instead of dispatching them immediately? So that widgets can peek ahead? No, so the messages can be executed when the program wants them to be. This is just by personal preference (easier for me to grasp the operations performed). 3. Implementation: GuiManager, GuiObject, GUI_* messages, input synthesis, and rendering I've already been working on this since October of last year, though I stopped somewhere in late December (work, etc.). I developed a GuiManager object, which provides methods for sending and posting messages, changing focus, and synthesizing input to appropriate GuiObject's. A GuiObject is an implementation of a widget. I successfully created a Button and Text widget, and a custom widget to test the button and text on. Jay mentioned that he was working on a GUI framework written in C++; not directly OHR-related at the time, but I believe built on gfx_directx? I said that the OHR needed such a thing to clean up the map and sprite editors, so I'd like to see whether we could reuse any of his code. Jay's uses message passing instead of callbacks/methods like GTK+ and wxWidgets do (actually I think wxWidgets does both, it's a mess). Methods don't work as well when your language doesn't support inheritance or virtual methods :) Message passing also has the advantage that you can easily catch messages of any
Re: [Ohrrpgce] Slice based menus
From: Jay Tennant hierand...@crazyleafgames.com Sent: Tuesday, February 21, 2012 6:45 AM From: Ralph Versteegen teeem...@gmail.com Sent: Tuesday, February 21, 2012 12:47 AM On 21 February 2012 06:46, Jay Tennant hierand...@crazyleafgames.com wrote: This is a non-OS specific goal. Everything is rendered inside the engine, as it is now. The objective is to make widgets that are intuitive for users. It is a native implementation. native implementation? What does native mean anyway? I always thought it meant provided by/tightly dependent on the platform (OS/hardware). Provided by/tightly platform dependent? Eh, no. Here's a picture: http://www.crazyleafgames.com/OutSourced/widgetExample1.png I think my vocabulary is a bit confused here. My usage of native was actually the opposite of the actual usage. Perhaps emulated would have been a better term. I was thinking native to the program. Doi! ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Slice based menus
On Tue, Feb 21, 2012 at 07:47:06PM +1300, Ralph Versteegen wrote: On 21 February 2012 06:46, Jay Tennant hierand...@crazyleafgames.com wrote: From: James Paige b...@hamsterrepublic.com Sent: Monday, February 20, 2012 10:00 AM I have been reading this whole thread, and I have to admit, I am totally confused. I am not sure at all what you are working on. Would you mind explaining this project to me? --- James Of course. I'll explain the problem, goal, and implementation of this project. I'll chip in as well... 1. Problem: the OHRRPGCE GUI lacks a uniform implementation I like the OHRRPGCE's interface, but it is difficult to upgrade it to be point-and-clickable. Additional monitoring would be necessary to capture the mouse coordinates and button presses. While that can be done for one menu, the lack of uniform implementation makes it troubling to monitor each menu. And if there was interest to adding more buttons later on, understanding context and rewriting the monitoring code could become daunting. It would be easier if the menu items were objects that could respond to operations performed on them--encapsulation. It would be easier if all menu objects interfaced the same way. It would be easier if there was a manager that uniformly passed messages to the appropriate menu objects that are the focus of the user's input. 2. Goal: create a GUI system that brings uniformity and flexibility to the rendering, interfacing, and management of menu's in the engine. This is for the graphical menus in Custom, of which there aren't many currently: font, sprite, tile, and map editors. The others are just lists of menu items and aren't included in this. The map and sprite editors have lots of different widgets visible onscreen, and the code for them is a mess because we have these monolithic functions that handle everything instead of splitting things up. The map editor and sprite editor code is terrible because it is some of the oldest code in the engine, and because I knew nothing about good design when I wrote it :) There is nothing inherently difficult about creating a complex irregular screen layout that prevents the code from being well organized-- it just doesn't happen to be that way right now :) I love the idea of being able to add callbacks to slices. Consider the sprite editor. I like the idea of having button slices that run a callback if you click on them. They could also have a key shortcut callback so that the existing keyboard shortcuts for them could continue to work. I also like the idea of mouse-down and mouse-up callbacks for the sprite drawing area. I was originally thinking that we would just use a slice to specify the position where the drawing area is located on the screen, and hand-code the rest, but it would be much better if the slice could recieve mouse and keyboard events and pass them on to appropriate sprite-drawing handlers. This is a non-OS specific goal. Everything is rendered inside the engine, as it is now. The objective is to make widgets that are intuitive for users. It is a native implementation. native implementation? What does native mean anyway? I always thought it meant provided by/tightly dependent on the platform (OS/hardware). There was also another goal: look into whether it would be possible to abstract different GUI frameworks. Maybe we could draw widgets using either slices, or something like wxWidgets (which I was especially interested in, due to my gfx_wx attempt) A GUI manager can create, destroy, and pass messages to widgets. A widget can optionally process the messages, or delegate the message processing to another widget. All widgets have a message procedure. Functionally, this is very similar to Window's design. Messages generated by the GUI manager are added to a queue, then processed in the order they are added. Why queue messages instead of dispatching them immediately? So that widgets can peek ahead? 3. Implementation: GuiManager, GuiObject, GUI_* messages, input synthesis, and rendering I've already been working on this since October of last year, though I stopped somewhere in late December (work, etc.). I developed a GuiManager object, which provides methods for sending and posting messages, changing focus, and synthesizing input to appropriate GuiObject's. A GuiObject is an implementation of a widget. I successfully created a Button and Text widget, and a custom widget to test the button and text on. Jay mentioned that he was working on a GUI framework written in C++; not directly OHR-related at the time, but I believe built on gfx_directx? I said that the OHR needed such a thing to clean up the map and sprite editors, so I'd like to see whether we could reuse any of his code. Jay's uses message passing instead of callbacks/methods like GTK+ and wxWidgets do (actually I think wxWidgets
Re: [Ohrrpgce] Slice based menus
On 2012-02-21, at 12:36 PM, James Paige b...@hamsterrepublic.com wrote: On Tue, Feb 21, 2012 at 07:47:06PM +1300, Ralph Versteegen wrote: On 21 February 2012 06:46, Jay Tennant hierand...@crazyleafgames.com wrote: From: James Paige b...@hamsterrepublic.com Sent: Monday, February 20, 2012 10:00 AM I have been reading this whole thread, and I have to admit, I am totally confused. I am not sure at all what you are working on. Would you mind explaining this project to me? --- James Of course. I'll explain the problem, goal, and implementation of this project. I'll chip in as well... 1. Problem: the OHRRPGCE GUI lacks a uniform implementation I like the OHRRPGCE's interface, but it is difficult to upgrade it to be point-and-clickable. Additional monitoring would be necessary to capture the mouse coordinates and button presses. While that can be done for one menu, the lack of uniform implementation makes it troubling to monitor each menu. And if there was interest to adding more buttons later on, understanding context and rewriting the monitoring code could become daunting. It would be easier if the menu items were objects that could respond to operations performed on them--encapsulation. It would be easier if all menu objects interfaced the same way. It would be easier if there was a manager that uniformly passed messages to the appropriate menu objects that are the focus of the user's input. 2. Goal: create a GUI system that brings uniformity and flexibility to the rendering, interfacing, and management of menu's in the engine. This is for the graphical menus in Custom, of which there aren't many currently: font, sprite, tile, and map editors. The others are just lists of menu items and aren't included in this. The map and sprite editors have lots of different widgets visible onscreen, and the code for them is a mess because we have these monolithic functions that handle everything instead of splitting things up. The map editor and sprite editor code is terrible because it is some of the oldest code in the engine, and because I knew nothing about good design when I wrote it :) There is nothing inherently difficult about creating a complex irregular screen layout that prevents the code from being well organized-- it just doesn't happen to be that way right now :) I love the idea of being able to add callbacks to slices. Consider the sprite editor. I like the idea of having button slices that run a callback if you click on them. They could also have a key shortcut callback so that the existing keyboard shortcuts for them could continue to work. I also like the idea of mouse-down and mouse-up callbacks for the sprite drawing area. I was originally thinking that we would just use a slice to specify the position where the drawing area is located on the screen, and hand-code the rest, but it would be much better if the slice could recieve mouse and keyboard events and pass them on to appropriate sprite-drawing handlers. This is a non-OS specific goal. Everything is rendered inside the engine, as it is now. The objective is to make widgets that are intuitive for users. It is a native implementation. native implementation? What does native mean anyway? I always thought it meant provided by/tightly dependent on the platform (OS/hardware). There was also another goal: look into whether it would be possible to abstract different GUI frameworks. Maybe we could draw widgets using either slices, or something like wxWidgets (which I was especially interested in, due to my gfx_wx attempt) A GUI manager can create, destroy, and pass messages to widgets. A widget can optionally process the messages, or delegate the message processing to another widget. All widgets have a message procedure. Functionally, this is very similar to Window's design. Messages generated by the GUI manager are added to a queue, then processed in the order they are added. Why queue messages instead of dispatching them immediately? So that widgets can peek ahead? 3. Implementation: GuiManager, GuiObject, GUI_* messages, input synthesis, and rendering I've already been working on this since October of last year, though I stopped somewhere in late December (work, etc.). I developed a GuiManager object, which provides methods for sending and posting messages, changing focus, and synthesizing input to appropriate GuiObject's. A GuiObject is an implementation of a widget. I successfully created a Button and Text widget, and a custom widget to test the button and text on. Jay mentioned that he was working on a GUI framework written in C++; not directly OHR-related at the time, but I believe built on gfx_directx? I said that the OHR needed such a thing to clean up the map and sprite editors, so I'd like to see whether we could reuse any of his code. Jay's uses message passing instead of callbacks/methods like GTK+ and wxWidgets do (actually I think
Re: [Ohrrpgce] Slice based menus
There's more further down, but separately, is there an equivalent high performance counter that is non-OS specific? Right now, the GUI framework uses Window's performance counter via QueryPerformanceCounter(), though that call is abstracted away in a virtual override to hide the OS dependency from the rest of the program. I suppose we could write a simple set of compiler directives to use the appropriate functions. I could alternatively just submit the code with the dependency, and let you decide what to do. From: Ralph Versteegen teeem...@gmail.com Sent: Saturday, February 18, 2012 10:26 PM On 17 February 2012 06:24, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@gmail.com Sent: Thursday, February 16, 2012 5:53 AM (Opps, I accidentally didn't send the last message to the mailing list) Oh well. Either way is fine for me, though I'm sure others may like to jump in. Opps again, I forgot to actually send to the mailing list. Actually doing so this time. On 16 February 2012 06:35, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@gmail.com Sent: Wednesday, February 15, 2012 7:45 AM On 14 February 2012 04:50, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@gmail.com Sent: Saturday, February 11, 2012 10:07 PM On 12 February 2012 06:32, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@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. I use valgrind for detecting leaks, but of course it's Linux and Darwin only. There are also many memory-debugging libraries which replace malloc/free, but I don't know how many of them can handle new/delete in C++. Oh ok. I may investigate this further in the near future, dependent on time. 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? I should have been clearer: I was only talking about the third group of messages. Although I can guess what most of them do, this seems like taking message passing to an extreme rather than storing a modicum of data on the window objects themselves. I see. Window's does store that data per window, and I was able to mimic that. (Except for the z-order. I only partially worked that out.) This allowed me to create a window that you could click-and-drag around the screen, while keeping all of its child windows (controls) relative to it. A custom window we create generally would never need to intercept the third set of
Re: [Ohrrpgce] Slice based menus
On 20 February 2012 03:21, Jay Tennant hierand...@crazyleafgames.com wrote: There's more further down, but separately, is there an equivalent high performance counter that is non-OS specific? Right now, the GUI framework uses Window's performance counter via QueryPerformanceCounter(), though that call is abstracted away in a virtual override to hide the OS dependency from the rest of the program. I suppose we could write a simple set of compiler directives to use the appropriate functions. I could alternatively just submit the code with the dependency, and let you decide what to do. In FB, TIMER should be used, as it already abstracts that. Otherwise, we could put OS specific code in our OS specific modules. From: Ralph Versteegen teeem...@gmail.com Sent: Saturday, February 18, 2012 10:26 PM On 17 February 2012 06:24, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@gmail.com Sent: Thursday, February 16, 2012 5:53 AM (Opps, I accidentally didn't send the last message to the mailing list) Oh well. Either way is fine for me, though I'm sure others may like to jump in. Opps again, I forgot to actually send to the mailing list. Actually doing so this time. On 16 February 2012 06:35, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@gmail.com Sent: Wednesday, February 15, 2012 7:45 AM On 14 February 2012 04:50, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@gmail.com Sent: Saturday, February 11, 2012 10:07 PM On 12 February 2012 06:32, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@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. I use valgrind for detecting leaks, but of course it's Linux and Darwin only. There are also many memory-debugging libraries which replace malloc/free, but I don't know how many of them can handle new/delete in C++. Oh ok. I may investigate this further in the near future, dependent on time. 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? I should have been clearer: I was only talking about the third group of messages. Although I can guess what most of them do, this seems like taking message passing to an extreme rather than storing a modicum of data on the window objects themselves. I see. Window's does store that data per window, and I was able to mimic that. (Except for the z-order. I only partially worked that out.) This allowed me to create a
Re: [Ohrrpgce] Slice based menus
On 17 February 2012 05:31, James Paige b...@hamsterrepublic.com wrote: On Fri, Feb 17, 2012 at 02:30:55AM +1300, Ralph Versteegen wrote: On 14 February 2012 04:28, James Paige b...@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. Yes, you are absolutely correct. I am only thinking about replacing built-in screens, and not thinking about usemenu/menudef stuff. I see now that I started out by stating something along the lines of it would be nice if someday all the built-in menus could be built using customisable/MenuDef menus and at some point I started assuming that they must be unified. I'm still attempting it, but I have a fresh point of view. 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? I think that MenuState type features are a different thing. But you are right. To do menuish things we do need another type of slice that encapsulates the features of the MenuState, and that would still be compatible with the SelectableSlices solution for more spatially complex but less menuish things. Now I see that MenuState-less slice selection could be useful for more than just targetting enemies: some menus like the load/save screen are weird. So maybe MenuSlices (the root of a menu's slice collection) and ItemListSlices (associated with a MenuState) should be separate things? I'll have to think about that more. Or rather, you could
Re: [Ohrrpgce] Slice based menus
On 14 February 2012 04:28, James Paige b...@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)
Re: [Ohrrpgce] Slice based menus
On Fri, Feb 17, 2012 at 02:30:55AM +1300, Ralph Versteegen wrote: On 14 February 2012 04:28, James Paige b...@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. Yes, you are absolutely correct. I am only thinking about replacing built-in screens, and not thinking about usemenu/menudef stuff. 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? I think that MenuState type features are a different thing. But you are right. To do menuish things we do need another type of slice that encapsulates the features of the MenuState, and that would still be compatible with the SelectableSlices solution for more spatially complex but less menuish things. Consider the Equip screen. The equip screen boils down to a collection of decorative and informational slices, plus two separate menus. One for the menu slots, and one for the available equipment. Suppose the slice layout template for the Equip screen has two MenuSlices, and two selectable slices. In this case, I guess there would be no place for focus handlers on the two SelectableSlices, they would just be there for changing the appearance of the two menus as focus changes between them, but the actual focus change would be done by selecting slots and equipment in the menus. SelectableSlices could work, but sounds like unnecessary complexity and something that should be abstracted a
Re: [Ohrrpgce] Slice based menus
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) *
Re: [Ohrrpgce] Slice based menus
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) 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
Re: [Ohrrpgce] Slice based menus
From: Ralph Versteegen teeem...@gmail.com Sent: Saturday, February 11, 2012 10:07 PM On 12 February 2012 06:32, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@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|
Re: [Ohrrpgce] Slice based menus
From: James Paige b...@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 ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Slice based menus
From: Ralph Versteegen teeem...@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) 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. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Slice based menus
On 12 February 2012 06:32, Jay Tennant hierand...@crazyleafgames.com wrote: From: Ralph Versteegen teeem...@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| +--+ ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
