Re: [AD] new pointer API

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2006-03-18, Cédric Lucantis <omer@xxxxxxxxxx> wrote:
> Hi!
> 
> I'd like to know if someone is actually working on the new pointer
> API, and if there's anything I can do to help (not sure I can, but
> I've got time and I _really_ need it :)

I think the pointer API as found here
http://alleg.sourceforge.net/future/pointer.txt is too complicated.

I've partially implemented a simpler mouse API in the `mouse_api' branch
in SVN, which hasn't been discussed yet.  The main design change was to
drop support for multiple pointers and to assume the one pointer is a
mouse.  I think it makes the common case much easier to code for, and
I'm not convinced that enough people would be writing multiple mouse or
graphic tablet applications to justify the extra complexity.

http://websvn.bafserv.com/wsvn/allegro/allegro/branches/mouse_api/?rev=0&sc=0

You could help by testing out and completing the drivers (one of the
Unix or Windows ones).  I don't think the 4.3 OSX port is in a state to
start working on the mouse driver.  Note also that the code in the
mouse_api branch is out of date with respect to the 4.3 branch, but I
can easily fix that by doing a merge (I was going to wait for 4.2.1
before merging).

> I also have a couple of suggestions about it (sorry if these have been
> discussed yet, I didn't find anything in the drafts) :
> 
> - a 'keyboard modifiers' field in AL_POINTER_EVENT : things like
> CTRL+CLICK are often used in video games (and GUIs in general) and
> just checking the keyboard state when the event is processed is not
> acceptable. Maybe is it not absolutely necessary because we can
> manually track the modifiers up/down events, but it would make that
> kind of commonly used feature easier to implement. Finally, it does
> not seem too hard to do or too expansive, am I wrong?

It's not hard and it would be useful, but it would introduce a
dependency between the mouse drivers and keyboard drivers so I'm not
sure we want to do that.

> - multiple clicks handling : once again not absolutely necessary, but
> would save some tricky work to the Allegro user. This could be either
> a specific event type or a 'n_clicks' field in AL_POINTER_EVENT. It
> also should be highly configurable to be really useful: click delay,
> send each click or not, max number of clicks... and eventually
> optional.

I'd introduce a new event type for this.  If the user wants something
highly flexible, probably he should be doing things himself using the
timer API.  So we should be able to do something that just covers the
common cases.

Peter





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/