From mint-bounce@lists.fishpool.fi Sat Apr 2 00:24:30 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: <424CE414.3080409@gabo.pl> References: <1111344400.12169.50.camel@taro.coolrunningconcepts.com> <424B0943.3000706@gabo.pl> <1112242300.10960.20.camel@taro.coolrunningconcepts.com> <424B8F47.7040803@gabo.pl> <1112294969.24071.20.camel@taro.coolrunningconcepts.com> <424C65AA.9070900@gabo.pl> <1112305473.24071.53.camel@taro.coolrunningconcepts.com> <424CE414.3080409@gabo.pl> Content-Type: multipart/alternative; boundary="=-q5PaGLsmq088zEFPZwuk" Organization: Cool Running Concepts Date: Fri, 01 Apr 2005 16:20:06 -0600 Message-Id: <1112394007.28763.9.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: --=-q5PaGLsmq088zEFPZwuk Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable On Fri, 2005-04-01 at 08:03 +0200, Adam K=B3obukowski wrote: > You need aditional condition, and fiddling with bits and stuff. With=20 > returning scancodes we do exactly the same thing, no matter what key was=20 > pressed. Uhmm .. how is this different? =20 > >>2. If we ever would want to add support for non-atari keyboards, we=20 > >>could run out of options > >=20 > > If you have a keyboard with more than 256 keys, its going to break the > > existing evnt_multi() and evnt_keybd() as well. >=20 > Well, more thatn 256 keys on a single keyboard is hard to find, I agree.=20 > But most modern keyboards these days has some multimedia keys, or just=20 > power on/off keys, and that do not fit very well into ascii. > As a ompromise we could return dwo words: a scancode in first, ascci + > modifiers in 2nd, how do that sound? Well, I think what you are saying is this: Method Adam: * New version of evnt_multi with additional parameters but mostly redundant code * Returns the same information, but handles 16 bit scancodes Method Evan: * Completely backwards compatible, no new calls, only a new event type * Limited to 256 scan codes. Typical PC keyboards have 105 keys. Leaving 151 unused scancodes. I think whenever you have to change an API, you make the programmer responsible for either picking which API they want to use, or making them responsible for correctly determining which APIs are available and providing the proper fallbacks and workarounds. How much variance of the API can such a relatively small developer base handle? And is it really necessary to code a new API to handle hardware that doesn't currently exist, won't exist under any platform for quite a long time (multimedia keys and such use a sequence of scancodes, which the OS doesn't necessarily give directly to applications) especially when no new hardware is currently in development now or in the foreseeable future? --=-q5PaGLsmq088zEFPZwuk Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-04-01 at 08:03 +0200, Adam Kłobukowski wrote:

You need aditional condition, and fiddling with bits and stuff. With 
returning scancodes we do exactly the same thing, no matter what key was 
pressed.
Uhmm .. how is this different?  

>>2. If we ever would want to add support for non-atari keyboards, we 
>>could run out of options
> 
> If you have a keyboard with more than 256 keys, its going to break the
> existing evnt_multi() and evnt_keybd() as well.

Well, more thatn 256 keys on a single keyboard is hard to find, I agree. 
But most modern keyboards these days has some multimedia keys, or just 
power on/off keys, and that do not fit very well into ascii.


As a ompromise we could return dwo words: a scancode in first, ascci +
modifiers in 2nd, how do that sound?

Well, I think what you are saying is this:

Method Adam:
  *  New version of evnt_multi with additional parameters but mostly redundant code
  *  Returns the same information, but handles 16 bit scancodes

Method Evan:
  *  Completely backwards compatible, no new calls, only a new event type
  *  Limited to 256 scan codes.  Typical PC keyboards have 105 keys.  Leaving 151 unused scancodes.

I think whenever you have to change an API, you make the programmer responsible for either picking which API they want to use, or making them responsible for correctly determining which APIs are available and providing the proper fallbacks and workarounds.

How much variance of the API can such a relatively small developer base handle?   And is it really necessary to code a new API to handle hardware that doesn't currently exist, won't exist under any platform for quite a long time (multimedia keys and such use a sequence of scancodes, which the OS doesn't necessarily give directly to applications) especially when no new hardware is currently in development now or in the foreseeable future?


--=-q5PaGLsmq088zEFPZwuk--