[Adonthell-devel] GUI module open items

[Kai Sterker]

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