Re: [AD] native filechooser addon

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sun, 2009-02-22 at 15:09 -0800, Evert Glebbeek wrote:
> On 22-Feb-09, at 1:41 PM, Peter Wang wrote:
> > Would it be extended for simple alert boxes and so on?
> 
> Not a bad idea, but where do we draw the line?
> I can see a use for "native" menus in such a tool too (in fact, in OS  
> X this would probably be easy, since every Allegro program already has  
> a menu bar). Presumably that's crossing that particular line? ;)

I'd say menus are too much. In the case of GTK it also would mean to go
at a much deeper level, basically a GTK display driver which creates a
GTK Window with a menubar widget and an OpenGL widget.

> 
> In my opinion, it should probably be a blocking call. In OS X, this is  
> also the expected behavior of a file dialog popup, so that's how I'm  
> thinking to implement it there.
> 

The problem is, Allegro's event queue would fill up fairly quickly if
you simply block the main thread - and when returning you'd have to
process 100ds of timer and inputs events all at once. And at least on my
X11, if the main window stops answering to events, the result is very
ugly in general. (Believe me, my first version of this did implement it
as a blocking call.) Of course, we could add some kind of pause mode to
Allegro where it discards most events and has some default answer to
redraw and similar events - but users can already do that easily
themselves.

-- 
Elias Pschernig <elias@xxxxxxxxxx>