Re: [AD] native filechooser addon

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sun, 2009-02-22 at 18:23 -0800, Evert Glebbeek wrote:
> 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.

I think any A5 program not using the events system is broken. If it was
for me, we would remove the functions to get "current" mouse/keyboard
state :P

> 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.

Yeah, I wanted to avoid having to provide another function to free such
an array (free() could not be used).

> 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.

Won't work under X11 right now as you need to handle at least window
redraw events at all times.

> 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?)

That sounds like a good idea. Basically I would just move some code out
of gtk_dialog.c into ex_native_file_chooser.c - it would keeping just
the same, just the native dialog implementations would have less to take
care of. I'll change it to that sometime today or tomorrow.

-- 
Elias Pschernig <elias@xxxxxxxxxx>