On 28.04.2010, at 11:50, Sparkaround wrote: > It seemed that this example code make the problem more clear.
No, sorry, not really. > The program will never exit if I press 'a' ! That's true, but due to the fact that the widget doesn't have the input focus and thus doesn't get the keydown event. Please add case FL_SHORTCUT: just below or above case FL_KEYDOWN: to make it the identical handling and test again. This should work with the 'a' key then (it does here). What processor (speed) do you use? Is it a local or remote X server? If remote, what network speed? For me it looks like an effect of queueing draw "events" in the X server event queue, so that the keypress events will be delivered and acted upon only after some (much) draw processing (with X11 server communication). But that's only an educated guess. I could partly replicate your effects by moving the window around on a Windows (Cygwin) X11 server. This moving of the window stops redrawing. After releasing the mouse, I could see that the window update doesn't act smooth as before, but "jumped" until it reached the end of the buffered drawing queue. During this period it didn't react on key presses, but when it reached the smooth state, everything was okay again. What happens if you change the delay from 0.001 to a much bigger value like 0.3 or so? Please keep in mind that Fl_Double_Window drawing will always be slower than Fl_Window drawing, and time critical usage should probably use Fl_Window. Another point: IIRC you did probably install the window resize patch from an STR that I don't recall now. That *might* be the source of (some of) your trouble. I still hesitate to commit that patch because I don't know if this would make much more X server communication for all WM's except FVWM. That said, another useful test would be without that patch, and maybe with another WM, but I don't know... Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
