On Fri, May 13, 2011 at 10:24:45PM +0100, Ian MacArthur wrote: > > On 13 May 2011, at 16:04, Kurt Van Dijck wrote: > > > >> I don't know enough Xlib to be sure, but I had the impression that it was > >> sent in response to the app requesting that the window be closed. > >> > >> It seems that Kurt has a (possibly non-standard) WM that is sending these > > > > I detected the problem with a non-standard WM, but that's the messenger > > here. > > Whenever XDestroyWindow is called by any external program, you're stuck. > > > > a WM is supposed to used WM_DELETE_WINDOW clientmessage, but no one says > > that XDestroyWindow() may not be called by anyone but the owner. > > > Hmm, I'm not so sure - I have the strong impression that I "knew" you are not > supposed to send DestroyNotify events to someone else, but I confess I have > no idea where I got that idea from.
DestroyNotify event is send by the XServer as a result of the XDestroyWindow. You're indeed not supposed to send it yourself to someone else. > > Has anybody ever seen this for certain, one way or the other? Or do we know > of any "standard" WM that does this? Just think it would be nice to know for > sure what is "normal" here! I have noticed this with a non-finisched WM. You should not find a WM that exposes the same behaviour, since the WM_DELETE_WINDOW atom is set. On the other hand, XDestroyWindow is a valid X11 api call, isn't it? If XDestroyWindow solves a problem, having FLTK not handle it properly is a bit frustrating. > > > > > >> events to the app, at times when the app has not requested to close the > >> window, so the state between the WM and fltk is getting messed up, and > >> fltk does nothing with the DestroyNotify event that it is not expecting... > >> > >> Kurt's patch maybe fixes his use-case, but I am not sure if it is strictly > >> valid or not for the general case. > > > >> > >> On the other hand, it might be entirely harmless to do it anyway, so... > > > > I'm not sure if it's strictly valid to do neither, but FLTK keeps closer to > > what > > is happening on X (window destroyed), instead of hanging around with a > > window > > that will never get any events anymore. I considered that an improvement. > > > I think that it does no harm to add your patch - but I can't tell for > certain; I don't know enough about what will happen internally to fltk if we > propagate a "synthetic" FL_CLOSE event in response to this message. > It looks reasonable > I guess, we'd need to try it more; Kurt, can you figure out what happens to a > multi-wondow app if this event is triggered to close one (or combinations, I > guess) of the windows? > I believe it's ok, but will try next week. > IS the behaviour sensible? The main problem is that FL_CLOSE does not _necessarily close the window. FL_CLOSE is generated when WM_DELETE_WINDOW is sent, but this latter acts as a kind request to do stuff. As long as the window's callback does hide() the window, it's no problem ... Only a few > Kurt _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
