Re: [AD] Windows Addition for Message Parsing

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 8 Oct 2008, at 09:58, Elias Pschernig wrote:
> As he needs the actual *Windows* messages - it always will be platform
> dependent. If we add something similar for OSX and X11, the user will
> have to deal with completely different messages, so guess it might as
> well be completely separate functions.

True. I have to admit that I don't know a great deal about how  
message passing works on all different platforms. What I had in mind  
was that if the message is mostly an integer that gets passed around  
(signalling "hey, the mouse has moved") without much more than that  
on all platforms, it would be possible to wrap that up in a platform  
neutral way. On the other hand, on OS X messages are already passed  
in a different way, so that's probably not going to work anyway.

> The ideal solution would be for us to add support for multiple mice so
> there would not even be the need to intercept platform messages. Not
> sure what the consequences for the API would be. Likely we'd need some
> kind of general device enumeration, instead of the classic
> one-mouse/one-keyboard/one-joystick idea (not sure about the  
> latter, it
> seems more advanced already). Likely not really worth the effort.

Well, apparently there's already one person who wants it. ;)
As a minimal change, could we have the following:
 * al_install_mouse() initialises the mouse subsystem and does an  
enumeration of the number of mice on the system (defaulting to 1 in  
case we don't implement that on some platforms for now).
 * We need al_get_number_of_mice() or something to that effect to  
return this information.
 * al_get_mouse() acquires a parameter to indicate events from which  
mouse it should be sending. Alternatively (making the common case  
easier), al_get_mouse() returns the first mouse and there is  
al_get_multiple_mice(int mouse_number) that registers a particular  
mouse for the event system. The mouse events then need an extra field  
to indicate what mouse generated the event.
 * Commands for affecting the mouse cursor or mouse state need an  
argument to decide what mouse to affect if there's more than one, but  
this can be done behind the scenes with al_set_current_mouse(),  
similar to al_set_current_display().

This leaves the common case of one mouse pretty much the same as it  
is now and implements multiple mice in a way that's similar to at  
least the display API (and presumably the joystick API too). I have  
to admit though that when I started writing I didn't think of the  
last bullet point on that list. ;) I was originally thinking that  
injecting the events would be easy and we'd just not bother with  
implementing multiple mice for al_get_mouse_state, just telling users  
to use the event system if they want multiple mice. However, we still  
need to be able to affect the cursor. :-/

Anyway, I'm not going to lose sleep over not supporting multiple mice  
(maybe I will lose sleep over not having some sort of built-in multi- 
button emulation though), but if someone wants it I'd rather it be  
implemented now and in this way that that we add a platform-specific  
mechanism for hacking it in.

Evert