| Re: [AD] new_api_branch news |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Very cool.
> * 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.
I was meaning to ask about that: were keyboards supposed to plug into the
graphic subsystem in the sense that a keyboard object is associated with a
particular window? Or do we just grab all keypresses and store the ID of
the window the input comes from?
About the graphics subsystem: I'm going to stick mostly with Bob's last
proposal. I am keeping AL_DISPLAY as something different than a BITMAP
though, as I think it makes sense to do that.
> * 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 don't think a lot of people use that function. It's probably ok to just
deprecate the behavior (I think).
Evert