Hi,
Another part of the GUI draft (window.html). Please give me your comments.
----------------------------------------------
<h1>The Window concept of PenguinGUI</h1>
<br>
<h3>Basic ideas</h3>
<p>Considering the fact that most widget libraries allow all widgets to
contain "sub-widgets", thus treating windows just as "widget with title bar
and border" it may seem strange that I denote such a big topic to them. So
you propably already guessed from this that we're taking a slightly
different approach.</p>
<p>But before I go into details about this issue, we should take a look
about the main requirements and ideas leading to our current model of
windows:</p>
<ol>
<li>Windows can be placed either on some 2D surface (see the 2D API,
Layer O for details) or in another window. The correct
implementation should be chosen automatically as soon as the target
type is known.</li>
<li>The main duty of windows is to contain widgets and to administrate
them. For this they have to provide some drawing surface to them,
filter/distribute incoming events and optionally keep track of
the "active control".</li>
<li>Looking at current games it should be unnecessary to let every
widget support sub-widgets. As such an approach would also imply
a certain performance penalty it should not be the default. But
nevertheless it should be not too difficult building widgets
behaving like this.</li>
<li>It has some well-defined background (color/image/...)</li>
<li>It should be optionally movable.</li>
<li>It should be optionally resizable (this is being discussed yet).</li>
<li>A title bar and border should be supported, but they are not
important enough to be an integral part of the windows
(being discussed).</li>
<li>Eventually the window should be able to deal correctly with
overlapping widgets (comments?).</li>
</ul>
<br>
<h3>The resulting design</h3>
<br>
<h4>Window placement/targets</h4>
<p>As stated above, windows should be fit for placement on some general
2d surface <em>and</em> in another window, according to the needs of
the situation. This requires that the "display" part of a window has to
include two different behaviors under one consistent interface.</p>
<p>As we are thinking OO, this can be done neatly through public inheritance
from some "ThingWhichIsDrawnOnSome2DSurface" class on the one hand and from
the "general Widget" class on the other hand - given that these two base
classes have similar (and of course virtual) interfaces.</p>
<p>I'm sorry that I cannot say more on this issue for now, but especially
the "2d surface" concept is quite new and thus changing rapidly. We'll
keep you informed.</p>
<br>
<h4>Widget administration</h4>
<p>As the window has to know about all the widget it contains it has to keep
some list of them, together with methods to add and remove widgets and to
check whether a certain widget is registered. Propably the registration
methods should also automatically (de-)establish some basic
<a href="signals.html">signal</a> connections.</p>
<p>The record about the "current control" is only optional, as it simply
is useless in several situations (e.g. when all compoments are
non-interactive). It is however required to provide correct event
distribution (e.g. only the active control may recieve keyboard events
that are not identified as shortcuts). See the
<a href="signals.html">event/signal</a> section for details on this.</p>
<p>How the drawing surface issue is handled I again cannot say yet
(see above). Please check the Graphics page and the mailing list for
latest information.</p>
<br>
<h4>Mixing window and widget functionality</h4>
<p>For being able to be registered in some other window every window has
to show widget behavior. The other way round - having every widget show
also window behavior - imposes IMHO too much unnecessary overhead. But
despite of this overhead it should be easy to build GUI components
which combine these two concepts.</p>
<p>Even if it seems quite surprising first, it proves to be quite easy
to fulfill all these requirements. On a second look however this becomes
clear:</p>
<p>To suffice the requirement "fit for placement in other windows"
(see above) we already chose "general Widget" as a base class for windows.
This has the obvious effect that a window becomes just a specialized
widget. So if someone wants to have his custom pushbutton support
sub-widgets, he just has to inherit from "general window" instead of
"general widget".</p>
<br>
<h4>Window background</h4>
<p>There need not to be said much about this - we just let each window
have a "2D image" as background, together with a placement attribute
(centered / top left / top right / ... / tiled / stretch to fit).</p>
<br>
<h4>Window movement</h4>
<p>Most windows used in computer games will have some fixed position,
but for some it certainly will be needed. As it is almost trivial to
implement I suppose every window will have a "move" method.</p>
<p>This does not mean that all windows will be movable by the user (player)
but only that they can accept the "move" order. For user controlled movement
see the <a href="#border">title bar and border</a> section.</p>
<br>
<h4>Resizing windows</h4>
<p>Resizing in this context means something like the resizing of
conventional GUI windows. The adaption to varying screen resolutions will
(if at all) be handled transparently by the 2D API.</p>
<p>As resizing should be generally not needed in computer games and
considering that it is quite difficult to implement for a bitmap-based
GUI I'm not sure whether it should be supported at all. Comments?</p>
<br><a name="border"></a>
<h4>Title bar and borders</h4>
<p>Most windows used in games will neither be movable by the user nor
resizabe, need a border, title bar etc, so it will be better to leave this
stuff out of the general "window" concept, thus reducing its size and
complexity. But as some game designers like to emulate conventional
GUI designs (which is no bad thing by the way) the option to add these
things to any window should be given.</p>
<p>I'm currently thinking about how that can be realized best, so don't
await anything concrete on this issue yet ;-)</p>
<p>My current favourite is to design the "title bar / border" combination
as some specialized widget and reserving one special slot for it in
the window class. But this may (well, quite sure it will) change in
the near future.</p>
<br>
<h4>Overlapping widgets</h4>
<p>Well, up to now I planned to simply expect that widgets in a window
don't overlap and thus let the windows ignore the according issues. As
I can't remember any GUI used in a game where widgets were overlapping
each other this seems to be a reasonable approach. But, well, I'm not
at all sure about it. Any Comments?</p>
<br>
<br>
<p><font size=-1><a href="index.html">Back to main GUI page</a></font></p>
<br>
<p><font size=-1>This document was written by
<a href="mailto:warewolf@chris2.mayn.de">Christian Reiniger</a>. Last
modification: 12.03.1998</font></p>
-----------------------------------------
Cu
Christian
Christian Reiniger (Germany)
e-mail: warewolf@chris2.mayn.de