On Thu, Oct 15, 2009 at 06:11:52PM +0100, Norbert Nemec wrote: > Joris van der Hoeven wrote: > >On Wed, Oct 14, 2009 at 05:27:03PM +0100, Norbert Nemec wrote: > > > >> > >>Indeed. I guess a proper approach on Qt would be to use processEvents > >>frequently during drawing. This does not work with the check_event gui > >>interface, but the necessary change in the interface should be minimal. > >> > > > >Can this indeed be done? Max told me that somethings are also disallowed > >during the painting phase in Qt. Can we process events during drawing, > >or should we first return to the main loop? Long live old-fashioned GUI > >API's... > > > I just found an ancient thread about calling processEvents from paintEvent > http://lists.trolltech.com/qt-interest/1997-08/thread00023-0.htm > > This seems to suggest that it is not impossible in principle, just a bit > tricky. > > Another source on the web warns in principle: > > http://www.kdab.net/~dfaure/conf/Malaga_AsyncProgramming/html/slide_5.html > > but this might simply refer to issues like the one discussed in the > thread before. As far as I see it, the main danger is that inside the > TeXmacs code, one must be aware that paintEvent might still be on the > stack. The whole thing certainly is tricky but I think it should be > possible.
Max: how feasable is the following strategy: check_event calls processEvents after setting a global variable that we are repainting something. In each of the event handlers, if this global variable is set, then either process the event if it is an independent non-blocking event, and transform the event in a delayed command if not, return to the repainting code and set the tell repainting to interrupt. Best wishes, --Joris _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
