Re: [AD] new_api_branch news

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2004-09-24 at 11:34 +1000, Peter Wang wrote:

> 
> * A work-in-progress patch implementing the last keyboard API proposal 
> from alleg-bigfive is available.  It works on Linux console, X, and 
> Windows.  Compatibility for the older keyboard API is present.  It's 
> pretty much done, just needs some more cleanup.
> 
> http://members.ozadsl.com.au/~tjaden/a5/nu/nu-keyboard-api-20040924.zip
> 
> The X keyboard driver no longer emulates keyboard scancodes to pass off 


I must look at that. My patch is almost ready as well, I just couldn't
get X synchronization to work yet (but inputing Chinese characters in X
works already :) Or does your patch also include support for that
already?

Did you change the way XLOCK/XUNLOCK works in any way? I'd like to
propose getting rid of XInitThreads and XLock/XUnlock, and use two
displays and pthreads locking instead. Using a separate display e.g. for
the events thread apparently makes X11 do its own locking, so the code
should look better (no more need for us caring about it) - and it makes
XIM work, which can't be used together with XInitThreads. For some
cases, like creating the displays and the initial window or maybe things
like position_mouse, I guess pthreads locks are needed to replace XLock.
The signals version is gone in new_api_branch anyway, so no need to care
about that..

> to the pckeys.c module.  The other two drivers work the same as they 
> used to.
> 

That should be changed. Keyboard should behave the same on all
platforms. Especially on windows I'd like to see a more sane behavior.
Using pckeys.c and keyboard.dat, we will never be able to support proper
internationalization. Which is a shame, given how early Allegro cared
about just that, even supporting unicode so early. Right now, you can
use Allegro's keyboard proplerly maybe in 3 or 4 countries. And I see no
reason at all why not to follow the way of the OSX or linux console (or
your new X11 driver I guess).

> 
> * How important is it to keep set_keyboard_rate() working?  In the new 
> API I haven't introduced an analogous function.  You just get whatever 
> repeat setting the OS gives you, which I think is the right thing to 
> do.  To maintain the same behaviour in the compatibility module I set up 
> an AL_TIMER which emulates the timing of whatever repeat rates the user 
> passes to set_keyboard_rate().  This is what Allegro 4 does, too, but it 
> uses install_int() instead.  It works fine, but I just wonder if it's 
> that important.  Otherwise the compatibility module could just use the 
> AL_EVENT_KEY_REPEAT events which are generated by the new keyboard API 
> anyway.  Right now it just ignores them.
> 

I think, we shouldn't touch the keyboard repeat rate. How my X11 patch
would have worked is this (using the current API):

The key[] array has no repeat. That is, generated repeats from the
hardware/OS are detected and ignored. A key is pressed until it is
released again. The KEY_ constants also don't care about their position,
but what is printed on them. Given their limited number, this can only
work for a few keys like latin letters, numbers, cursor keys, but not
e.g. for keys like \ or ~ which don't even exist on my keyboard.

getkey() OTOH will use the keyboard rate as reported from the OS, since
that's what the user has set and wants to use e.g. in inputs boxes in
the grabber. And it will return whatever is printed on the key that is
pressed, using the same Shift/AltGr/dead-keys behavior the user is used
to.

> BTW, the Windows keyboard driver has to do extra work to generate 
> AL_EVENT_KEY_REPEAT events anyway, so the autorepeat emulation is done 
> _twice_ there if you use the compatibility module.  Once for the new 
> API, emulating the setting from the Control Panel, then a second time to 
> emulate the setting from set_keyboard_rate() :-P
> 

I think we don't have to keep set_keyboard_rate working. It can just do
nothing.

Oh, btw,

struct _AL_THREAD
{
    /* private: */
    pthread_t thread;
    pthread_mutex_t mutex;
    bool should_stop;
    void (*proc)(_AL_THREAD *self, void *arg);
    void *arg;
};

What is "bool"? I thought that is C++ only?

-- 
Elias Pschernig