[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GUI draft - mouse pointer



Hi,


Sorry for not witing a nice introduction to each file, but I just can't  
imagine so much ;*)

But as always: I love comments ;)

-------------------------------------------
<h1 align=center>The PenguinGUI Mouse pointer concept</h1>

<em>Page under construction</em>

<br>
<a name="basic_list"></a>
<h3>Main Questions ...</h3>

<ol>
	<li>First of all - why should the mouse pointer be
		<a href="#control_by_gui">controlled by the GUI</a>?
		system?</li>
	<li>Should there be support for
		<a href="#multiple_pointers">multiple mouse pointers</a>,
		and/or multiple mice?</li>
	<li>What kind(s) of
		<a href="#target_surface">target surface(s)</a>
		for mouse pointers should exist?</li>
	<li>What's the best way for the
		<a href="#representation">graphical representation</a>?</li>
	<li>Is support for
		<a href="#multi_representations">multiple graphical
		representations</a> per mouse pointer needed/useful?</li>
	<li><a href="whatelse">What else</a> has to be considered?</li>
</ul>


<br>
<h3>... and their Answers</h3>

<br>
<font size=-1><a href="#basic_list">Up to list</a></font>
<a name="control_by_gui"></a>
<h4>Why should the mouse pointer be controlled by the GUI system?</h4>

<p>To be able to answer this question we first have to examine what the
mouse pointer is used for (this topic is also closely related to
the question about the <a href="#target_surface">target surface</a>).
</p>

<p>In many games the mouse pointer is mainly used for interaction with
some scene independent from the GUI system, e.g. some map in a strategy
game, a 3D scene in a 3D shooter etc. Some of these use no interactive
GUI elements, others have some kind of interactive status bar fixed to
one screen side, interactive dialogs popping up from time to time etc.</p>

<p>Ok, in each of the cases there has to exist some instance controlling
the mouse pointer. In the first case this instance has to notify the
module controlling the scene about changes in the mouse pointer's status
(position, pressed buttons etc), in the second case it also has to know
about the (currently displayed) GUI windows - or at least has to tell
the GUI about each status change.</p>

<p>This leads to three different approaches (please tell me if you see
more).</p>

<p>In the first approach the instance controlling the mouse pointer
belongs to the subsystem controlling the displayed scene. It has the
advantage that it could have immediate knowledge about objects displayed
in this scene. On the other hand it would know nothing about the GUI
objects and has to blindly notify the GUI system about every change.</p>

<p>The second approach uses some independent authority for mouse pointer
control - with the problem that neither the scene nor the GUI can be
directly supported.</p>

<p>As third possibility the mouse pointer would be controlled by the
GUI system. This instance knows (of course) about all GUI elements
currently displayed. It however knows no details about the displayed scene
- almost the same situation as in approach one. But it has some real
advantages:</p>

<ul>
	<li>In most cases the 2D/3D scene will ge the screen background with
		the GUI elements floating over it. So the GUI should be informed
		about a mouse status change <em>before</em> the underlying scene.
		As the GUI system knows about the GUI windows and their positions,
		sizes etc it can easily distinguish whether one of the windows has
		to be informed or the underlying scene.</li>
	<li>The GUI will (as far as I can see now) support "virtual screens",
		i.e. widgets that also behave like screens. Such a virtual
		screen can for example contain another scene which will usually
		be controlled by the mouse pointer of the "mother screen".
		As the GUI system knows about the virtual screen it can
		automatically transform mouse coordinates into its local
		coordinate system, thus allowing really transparent handling
		of these VSes.</li>
</ul>

<p>Besides - if you (again) take the phrase "Graphical User Interface"
in its literal sense, a mouse pointer fits really well into it. So I
think it's the best thing to let the GUI control the mouse pointer.</p>


<br>
<font size=-1><a href="#basic_list">Up to list</a></font>
<a name="multiple_pointers"></a>
<h4>Should there be support for multiple mouse pointers and/or
	multiple mice?</h4>

<p>As we are using <a href="http://www.ggi-project.org">GGI</a>
for the lowest level graphics (and perhaps also for parts of the input)
and as GGI supports multiple mice, it seems only logical to support
multiple mice (and thus multiple mouse pointers) with the GUI system,
too.</p>

<p>Of course this functionality has to be useful - otherwise it's just a
waste of time and resources to include it. So how can a game take advantage
of multiple mice?</p>

<p>One possible scenario is a multiplayer game supporting several players
at one physical machine via splitscreen or several physical screens
(which are also supported by GGI). Here each player could use his own
mouse, controlling his own mouse pointer.</p>

<p>Perhaps it can even be useful to allow several mouse pointers on one
screen for ambidextrous control (comments?).</p>

<p>Looking at the above list and considering that there exists very little
experience with multiple mice (so it's quite likely that new uses will be
found in the future) it looks like a good thing to include. And, well, it
should not be too difficult to implement.</p>


<br>
<font size=-1><a href="#basic_list">Up to list</a></font>
<a name="target_surface"></a>
<h4>What kind(s) of target surface(s) for mouse pointers should exist?</h4>

<p>This is a quite difficult question, especially because I don't know the
current specifications of the graphics part well enough and thus have no
good overview about what exists. And, besides, I didn't reflect enough
about that topic to know what is needed ;) I'll keep you posted.</p>


<br>
<font size=-1><a href="#basic_list">Up to list</a></font>
<a name="representation"></a>
<h4>What's the best way for the graphical representation?</h4>

<p>This in turn is an almost trivial issue. A mouse pointer is IMHO
just a specialized sprite, so I'll plan to use directly the "sprite"
concept of the 2D system for it (Link coming soon). It is flexible enough
yet includes only the required functions, thus minimizing overhead.</p>


<br>
<font size=-1><a href="#basic_list">Up to list</a></font>
<a name="multi_representations"></a>
<h4>Is support for multiple graphical representations per mouse pointer
needed/useful?</h4>

<p>Imagine a mouse pointer in some fantasy adventure. Usually it will look
like some sword, but as soon as it moves over a general item its shape
changes into that of a hand. Floating over a book or picture it looks like
an eye and over doors it takes the shape of a key.</p>

<p>This kind of behavior is common in "traditional" GUIs and also used
quite often in games. It uses a set of images for the mouse pointer to
illustrate the effect of clicking in the current context, making the game
handling much more intuitive - a very useful feature that really should be
supported by our API.</p>

<p>The PenguinPlay GUI system will allow a mouse pointer to store a
repository of images that can be switched with one simple command. Whether
there will be a maximum number of storable images is not certain yet,
but it should not be necessary (and I don't like limits at all).</p>


<br>
<font size=-1><a href="#basic_list">Up to list</a></font>
<a name="whatelse"></a>
<h4>What else has to be considered?</h4>

<p>There are some smaller issues that have to be noted, too:</p>

<ul>
	<li>For Drag'n'Drop and similar mechanisms it is very useful if the
		mouse pointer can temporarily take the look of the dragged
		item or be merged with it.</li>
	<li>For now I can't imagine more, but I'm sure there are still
		quite some important issues around. Please tell
		<a href="mailto:warewolf@chris2.mayn.de?subject=PPlay-MousePtr">
		me</a> if you find something.</li>
</ul>

<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: 01.04.1998</font></p>
--------------------------------------------


Cu
        Christian


Christian Reiniger (Germany)
e-mail: warewolf@chris2.mayn.de