As promised, here's a list of open items for the GUI module. I'll follow this up with another mail with details regarding some actual user interface implementation work. I guess there are 3 big open items.
1. Window manager "layers" or "window types" Right now the window manager treats all windows/UI elements equally. The last one that gets displayed will receive input focus and that's about everything it does. Extrapolating from what we had with Waste's Edge, I think we'll have to support at least 3 different kinds of UI elements: * HUD. These elements (like health or mana bars, quick slots, etc.) are on the lowest layer and often interactive. (Although I guess any useful interaction would require mouse support). * Popups: Like the speech bubbles in Waste's Edge. Above the HUD, but below actual windows and usually not interactive. * Toplevel: All the rest, like game menu, load/save screen and such. Above everything else, with the topmost having input focus. So the window manager should be extended to allow setting the window type when adding a new window and handle it accordingly. 2, Grid layout widget Like list_layout, but 2-dimensional. It should be good enough to assume that each cell in the grid is of equal size (that of the first element added), Adding elements should be possible via something like insert_child(widget, x, y). preferably without having to specify the number of rows and columns in advance. Like list_layout it should support the different ResizeModes, keyboard navigation and scrolling via the scrollview widget. The main use I see for the grid_layout widget would be for an inventory view, where you'd have a number of fixed size slots. For a list with multiple columns, a list_layout where each item is a layout itself should be the better choice. Therefore I don't think the grid layout needs to be very complex, just a convenient way to automatically arrange multiple, identical, elements on a rectangular area. 3. Mouse support. The input module already takes care of mouse input, but the GUI module doesn't. It does have some (commented) code that would handle mouse input directly via SDL, but that could be out-dated. Like with keyboard/gamepad support, the GUI module needs to make use of the mouse events the input module provides. In general, I don't think mouse support has a high priority, but it would be required to support systems where input is usually via touchscreen. (Think tables or smartphones). If we really add mouse support to the GUI, we may also have to allow controlling the rest of the game via mouse, for consistency. Although I'm still leaning towards a user interface that's optimised for gamepad/keyboard input. Feels more direct/immersive to me than pointing and clicking with the mouse. Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel