From mint-bounce@lists.fishpool.fi Thu Mar 31 06:15:58 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] New AES keyboard messages From: "Evan K. Langlois" To: Adam =?iso-8859-2?Q?K=B3obukowski?= Cc: mint@fishpool.com In-Reply-To: <424B0943.3000706@gabo.pl> References: <1111344400.12169.50.camel@taro.coolrunningconcepts.com> <424B0943.3000706@gabo.pl> Content-Type: multipart/alternative; boundary="=-W2I/1k7/a8/AooBhGeKY" Organization: Cool Running Concepts Date: Wed, 30 Mar 2005 22:11:39 -0600 Message-Id: <1112242300.10960.20.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, HTML_MESSAGE X-Spam-Level: --=-W2I/1k7/a8/AooBhGeKY Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable This is basically what X does if I remember right. You get a "Key Down", "Key Press", and "Key Up", and you can ignore the Key Down and Key Up messages most of the time and just use Key Press, but games and things of that sort use just the Key Down and Key Up messages mostly. I don't know how this would fit into the current AES evnt_multi() call. Perhaps, add a KEYSTATE event mask type to evnt_multi() so when waiting on this you would get the Key Down and Key Up events. The KEYSTATE event wouldn't even need extra places to store the information. The key would be returned in the same manner as regular keyboard events, and the state could be another bit returned along with the status of the keyboard modifier keys (Shift, Control, Alt, etc). If you use both the existing keyboard (key-press) events and the newer Key-State, we could return "Key Down" and the regular AES Keypress at the same time (the data is compatible) to consolidate events if needed. For key-repeat, you'd get a new Key-Down with the keypress, then 1 or more keypress events, and then a keypress with a Key-Up, although I'd bet, for games and such, you'd turn off the old keyboard event so you don't get all repeat keys and just look at the Key Down and Key Up. How's that sound? -- Evan On Wed, 2005-03-30 at 22:17 +0200, Adam K=B3obukowski wrote: > Hello >=20 > I have idea of new type of messages AES could deliver to applications. >=20 > The messages are Key pressed, Key released. >=20 > Key pressed is sent only once when key is pressed, no mater what=20 > keyrepeat would produce. > Key released is also sent only once, when key is released. >=20 > That messages can be sent interleaved, ie when user presses multiple key=20 > at the same time. >=20 > That messages should be new class of the messages, not included in any=20 > other class (esp. keyboard messages), for a call like event_multi. This=20 > is so application/AES would not need to waste time for handling unwanted=20 > keyrepeat messages. >=20 > The main reason for adding this messages is SDL and gaming in overall=20 > under AES. >=20 > (btw. SHIF, ALT, CONTROL should be also sent as such messages) >=20 > Technical details lik API/ABI are left for discussion. >=20 > Thanks for Ozk for being interested. >=20 --=-W2I/1k7/a8/AooBhGeKY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is basically what X does if I remember right.  You get a "Ke= y Down", "Key Press", and "Key Up", and you can ig= nore the Key Down and Key Up messages most of the time and just use Key Pre= ss, but games and things of that sort use just the Key Down and Key Up mess= ages mostly.

I don't know how this would fit into the current AES evnt_multi() call.&nbs= p; Perhaps, add a KEYSTATE event mask type to evnt_multi() so when waiting = on this you would get the Key Down and Key Up events.  The KEYSTATE ev= ent wouldn't even need extra places to store the information.  The key= would be returned in the same manner as regular keyboard events, and the s= tate could be another bit returned along with the status of the keyboard mo= difier keys (Shift, Control, Alt, etc).  If you use both the existing = keyboard (key-press) events and the newer Key-State, we could return "= Key Down" and the regular AES Keypress at the same time (the data is c= ompatible) to consolidate events if needed.  For key-repeat, you'd get= a new Key-Down with the keypress, then 1 or more keypress events, and then= a keypress with a Key-Up, although I'd bet, for games and such, you'd turn= off the old keyboard event so you don't get all repeat keys and just look = at the Key Down and Key Up.

How's that sound?

-- Evan

On Wed, 2005-03-30 at 22:17 +0200, Adam Kłobukowski wrote: 
Hello

I have idea of new type of messages AES could deliv=
er to applications.

The messages are Key pressed, Key released.

Key pressed is sent only once when key is pressed, =
no mater what 
keyrepeat would produce.
Key released is also sent only once, when key is re=
leased.

That messages can be sent interleaved, ie when user=
 presses multiple key 
at the same time.

That messages should be new class of the messages, =
not included in any 
other class (esp. keyboard messages), for a call li=
ke event_multi. This 
is so application/AES would not need to waste time =
for handling unwanted 
keyrepeat messages.

The main reason for adding this messages is SDL and=
 gaming in overall 
under AES.

(btw. SHIF, ALT, CONTROL should be also sent as suc=
h messages)

Technical details lik API/ABI are left for discussi=
on.

Thanks for Ozk for being interested.
--=-W2I/1k7/a8/AooBhGeKY--