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

[Gubinelli Massimiliano]

Hi all,

On 15 oct. 09, at 22:02, Joris van der Hoeven wrote:

> 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.


I agree that something like this should work. What about the following  
more uniform scheme:
each Qt event handler performs some basic computations (which do not  
require involvement of TeXmacs objects)
enough to determine an appopriate function call into TeXmacs which is  
then boxed as abstract command  and inserted in the
delayed messages  queue. This would allow to return as fast as  
possible to the event loop. Inside check_events should then be safe to  
call processEvents which could result in filling up the delayed- 
messages queue by some input commands (keypresses or mouse movements).  
If this is the case we can set some flags so that check_events can  
interrupt the drawing process and return to the main event loop. At  
this point the delayed messages can be processed. This would have the  
added bonus of giving us the control of the events already  
preprocessed so that, for example, we can skip some mouse move events  
if they are too many, or process all the key events, etc...
I still have some doubts about the handling of socket events.

Max