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

Re: [MiNT] New AES keyboard messages

On Fri, 2005-04-01 at 19:23 -0500, Lonny Pursell wrote: 
on 4/1/2005 5:20 PM, Evan K. Langlois wrote:

>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?

I don't see any relationship to variances in the API and the size of the
developer base.  Sorry, but that comment makes no sense whatsoever to me. If
a given call is properly documented, it's a no brainer.  The developer can
use the call, or not use the call.

You don't see a problem if there are more APIs than developers or users?  or at least a really high ratio.  How bloated is an application if they have to check for every extension and then provide different code paths for each variance?   I just can't see having two different versions of evnt_multi() just so the key-up/key-down extension can support 65535 scan codes instead of 256.  I don't see any possibility of Atari apps needing keyboards with more than 256 keys any time in the near future.  I definately think such an extension would be more likely to be used by application developers if they didn't have to dump evnt_multi() for a new version.

Honestly, the whole idea of throwing out existing APIs and conventions for hardware that doesn't even exist, especially when the userbase and developer base is already highly fragmented so as to make the use of such new calls questionable .. just seems ... crazy!  If something works, don't fix it.

Being able to detect keys being held down and ignore key repeat and stuff like that, seems like a useful feature if it can be done without breaking current APIs and conventions.  I don't see a need to break existing conventions and APIs when they work fine, and will continue to do so for the forseeable future.  I'm way against arbitrarily increasing the size of the scancode parameter to 16 bits.  Its 8 bits now, and should stay that way.

If someone wants to spend the time... they will.  Remember, it's their time,
not yours.
Oh wow!  I shouldn't care about the developers?   Just screw them, huh?  Who else is the OS API for?