[Adonthell-devel] Layout: widget or not?

[Kai Sterker]

Brain storming about the GUI API. for discussion and for making the
options and consequences clear to myself.
Right now, our GUI still pretty much looks like this:
http://adonthell.berlios.de/doc/index.php/Widget_Set

Not shown on this picture is the window_manager, which is responsible
for drawing all open windows on screen, give focus to the topmost and
so on. With the current implementation, only widgets can be added to
the window manager.

So to implement something like a dialog that should be displayed by
the manager you'd do:

    class dialog : public widget
    {
    protected:
        layout Container; // all child widgets of the dialog could go in here
    };

Furthermore, all input the dialog receives must be forwarded to the
layout container. For example:

    bool dialog::keydown(input::keyboard_event &k)
    {
        return Container.keydown(k);
    }

All in all there are three types of key events (And we haven't
implemented mouse or gamepad support for the GUI yet).

But if a layout was a widget, we could do the following and worry no more:

    class dialog : public layout
    {
    };

Of course, if a layout is a widget, then the distinction between
widget and base doesn't make much sense anymore and the two should be
combined. Under "Possible Changes", Rian already suggested as much
himself.


Another issue is the fading, which right now is a function of layout.
The problem is that with layout::draw being const, we cannot use the
original implementation. But doing fading in a different method means
we have no access do x and y location of the layout, which is needed.
Now, the more I think about it, I believe that fading should be part
of the window_manager. I.e. on adding or removing a window, you could
optionally specify a fade type. The window_manager is supposed to know
the position of each child it contains and it has the advantage of
having a non-const update() method that gets called once for every
frame. Ideal to handle fading in/out of dialogs. (A word of caution
here: don't expect the fancy effects you might be used from OSX or
Compiz. We can move a window from off-screen to on-screen and vice
versa or with some additional coding fade from or to transparency,
nothing more)


Well, I think that settles it. Layout becomes a widget, base will be
incorporated into widget and fading moves to window_manager. I might
not manage do much of this today, so if you have any additional input,
it'll be appreciated. Otherwise expect the next large GUI commit by
the weekend at latest.

Kai