Re: [Texmacs-dev] Two fixes for delayed execution

[Joris van der Hoeven]

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