Re: [AD] native filechooser addon

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

Ok, I've thought about it a bit more. I now think the current file  
selector API is broken. The reason I now think this is because it uses  
the event system to return its results, but there is no logical reason  
why it should work that way. In a sense, it's abusing the event system.
It also forces users who don't (want to) use the event system to use it.

So. Here's what I currently think: the file selector should be a  
blocking function on all platforms, returning the number of files  
selected, 0 if the file selector was cancelled, or -1 if it isn't  
available on the target platform. There is the question of how to  
return the results, but the user could be told to pass in an  
ALLEGRO_PATH** that we allocate and fill (not sure; essentially we  
need a way to return arbitrarily many values). We document that this  
is a blocking function.
When calling this function, the user has two options: the first is to  
process all events in the queue before this function is called and  
flush all queues afterwards. Yes, this means window close events will  
be ignored. I don't think that's a problem, it's the normal behavior  
on OS X anyway.
The second is that the user calls the blocking function from a  
separate thread, and ejects the result in the event queue when he's  
done. This is essentially what the current implementation forces you  
to do anyway (in which case the user abuses the event system but  
Allegro's API doesn't, I think that's ok). This also cleans up the  
need to steal another event ID (by the way, what happened to using  
AL_ID's for event types?)

Thoughts?

I'll clean up my OS X file selector when it's clear what the API  
should look like.

Evert