> Manolo has added: > > ------------------------------------------------------------------------ > r8653 | manolo | 2011-05-11 19:09:43 +0100 (Wed, 11 May 2011) | 3 lines > > On Mac OS, FL_HIDE is now sent when a window is minimized or the > application is hidden. > The context removal on Fl_Gl_Window::handle() destroyed the GL colors > when the window=20 > is remapped. > ------------------------------------------------------------------------ > > Is this what we want to do? I mean sending FL_HIDE when the window is > minimized? > > There are no side-effects to doing this? (I mean it does not > inadvertently cause some apps to exit because it thinks all the windows > are hidden so Fl::run(); returns?) > > I guess it is OK, but it just seemed a bit odd to me when I looked at > it...
There's a confusion here, because this thing is indeed confusing. Fl::handle(FL_HIDE, window) is now called under OS X when a window is minimized or when the application is hidden. This calls Fl_Widget::hide() of the window, which sends the FL_HIDE event to all visible widgets of the window. Many widgets ignore FL_HIDE, but those that are drawn differently with or without the focus react to this event. Others react to this event because it makes a difference if the window is on screen or invisible or minimized (Fl_Clock for example stops ticking). All of this is very different from calling Fl_Window::hide() that deletes the window and all associated objects, and removes it from the list of FLTK windows, potentially finishing the Fl::run() loop. The confusion is easy between Fl_Window::hide() and Fl_Widget::hide(). The current OS X behaviour does the right thing (send the FL_HIDE event to visible widgets), and not the wrong thing (delete the window object). _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
