GUI draft - keyboard buffer

[WareWolf@chris2.mayn.de (WareWolf)]

Hi,


Another part of the GUI draft (the keyboard buffer).
Please comment...


------------------------------------------------
<h1 align=center>The Keyboard Buffer of PenguinPlay's GUI system</h1>

<em>Page under construction</em>

<br>
<h3 align=left>Introduction</h3>

<p>A keyboard buffer is something that stores characters entered via the
keyboard until its client asks for them. It prevents that a busy or slow
client misses some keystrokes and it adds flexibility to keyboard input.</p>

<p>Ok, so this buffer stores <em>characters</em>. This means that it is
used for text input and eventually also keyboard shortcuts. It is
definitely not suited to serve clients requiring raw keyboard status
(e.g. the movement control of a 3D shooter).</p>

<p>Text input is exclusively handled via the GUI, keyboard shortcuts can
also be accepted by other parts of a game (e.g. the "select weapon" keys).
The first case leads to the assumption that the keyboard buffer should
be handled by the gui system, as it knows best who will and may accept
the input. For the shortcuts case a keyboard buffer controlled by the
Input system seems to be better.</p>

<p>Well, actually I don't know yet where to place it. Perhaps the shortcut
problem can be solved using something like a invisible "shortcut widget".
I'll keep you informed.</p>

<br>
<h3 align=left>Features</h3>

<p>I'll simply start to write down a basic specification of the keyboard
buffer, whether or not it will be handled by the GUI. So what features
are needed?</p>

<ul>
	<li>The buffer has to be organized as a queue, i.e. a FIFO
		(first in, first out).</li>
	<li>It must be capable of storing characters (ASCII or better Unicode)
		and some control keys (cursor keys, del, end...).</li>
	<li>Distinction between "normal" keys and those on the numeric
		block is not needed (and not wanted). For this, the status of
		"num lock" has to be processed automatically (the same holds
		for the "caps lock" status).</li>
	<li>Perhaps it is convenient to store toggles (scroll lock, insert etc)
		also as "characters". This ensures that everything is processed
		in the right order.</li>
	<li>Modifiers that don't directly modify the ASCII value of the
		character (e.g. Alt, Ctrl, ...) have to be stored together
		with the character value. Perhaps we can use 32-Bit values
		with the modifiers etc stored in the high word16 and the Unicode
		character value in the low word16.</li>
	<li>The buffer has to provide a method for emptying it (e.g. as
		emergency cleanup for very slow clients or on client shutdown).
		</li>
	<li>To avoid characters being processed long after the User stopped
		entering them (an effect common to very slow consoles) it has
		to be possible to limit the time the characters may stay in the
		buffer queue.</li>
	<li>It can be useful if the buffer can be resized at run-time. This
		has the advantage that each client can adjust the buffer size
		to the situation-specific needs.</li>
	<li>The effects of a buffer overrun have to be selectable or at
		least defined. Possible effects are: automatic resizing, exception
		throw, ignoring incoming characters.</li>
	<li>If multiple keyboards (perhaps faked) are supported, it's also
		necessary to support multiple buffers.</li>
	<li>Automatic identification of keyboard shortcuts has to be
		performed.</li>
	<li>A method indicating whether the buffer is empty or not is
		unnecessary, as everything is event controlled.</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: 02.04.1998</font></p>
----------------------------------------------


Cu
        Christian


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