> David Ibbitson wrote: > > I've noticed that Fl_Native_File_Chooser seems to block events > > in Fl_Gl_Window. > > Yes, while the chooser is open, the rest of FLTK is "blocked" > IIRC. That is pretty much the only way it can work, I think, > due to how the chooser has to use OSX's own application loop. > > > I have an animation taking place in my OpenGL > > window based on add_timeout/repeat_timeout. When I open > > Fl_Native_File_Chooser, (which partially covers the window), > > my animation stops. If I cancel, the animation resumes, > > There might be a way to modify this to keep FLTK alive, > but I'm not sure that's a 'safe' thing to do. > > I coded FNFC, but admittedly don't know enough about how > FLTK/OSX integrate at the lower level to know if it's possible > to have the native chooser open at the same time FLTK events > are allowed to be processed. > > > and > > if I click ok, the image in the window freezes, like its > > not swapping back buffer to front. > > Ew, that does sound like a bug.
Yes, but like I said its not necessarily FNFC. I've been using FNFC for a couple years now with no problems. This OpenGL thing seems to have only cropped up since the 10.5.3 update. > > Strangely taking > > out glFlush() in my draw() function seems to fix this. > > Greg, I'm just wondering if its normal for the chooser > > to "block events". > > Yes, as written I think it is. > > I'm not sure it has to be that way though.. some advice from > Matthias might be needed here, or someone familiar with the > intimacies of FLTK <-> OSX event processing to look over my > OSX specific code in FNFC to see if using the FLTK event loop > would be possible while the native chooser is open. > > > I also tried Fl_File_Chooser, and my > > animation continues uninterrupted. > > Right, because it's an FLTK oriented chooser, FLTK can be > alive during the event loop. Ok, at least I'm clear on that now. It makes sense to me that the FLTK chooser can allow events to proceed (atleast timeout events), and also that FNFC can not because it relies on Carbon specific events processing. I've looked at the the FNFC mac code, and even compared it to the Apple docs (http://developer.apple.com/documentation/Carbon/Conceptual/ProvidingNavigationDialogs/nsx_intro/chapter_1_section_1.html) and I can't find anything glaringly obvious that could be wrong. > > Next, this problem may have popped with the with 10.5.3 update. > > I'm just wondering if anybody has noticed any problems with > > FLTK and OpenGL because of this update. > > The GL specific freeze problem does sound like a bug somehow. > > You might need to do the flush before opening the chooser > or something. > > If you can show me a small, compilable example program that > demonstrates this, I'll see if I can figure it out. > > At some point FNFC implementation needs to be 'blessed' > by the FLTK core folks to ensure it's properly implemented, > as it does get into platform specific event management > which has bitten me before. Thanks for the feedback. I'm going to try explicitly stopping the timeout events before I show the chooser dialog, and also try flushing before as well. I'll try to put a little demo together. Allthough its probably one of those things where its difficult to recreate the problem. My only lingering thought is that somehow but stopping the FLTK events processing, a "redraw" is not going through when it should be. Will do more testing. Cheers, David _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
