texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Qt port problem


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Qt port problem
Date: Fri, 13 Sep 2002 18:09:30 +0200 (MET DST)

> > > I am stuck when trying to deal with X event because I transmit them too
> > > soon so edit_interface_rep::handle_repaint (repaint_event ev)
> > > complains.  Can you tell me at which time it is safe to handle events?
> > 
> > I am not sure whether I understand your question well.
> > Repainting is indeed quite complex, because we test whether new events
> > occur during this phase. You may wish to disable this behaviour for
> > a first working port.
> > 
> 
> Because of Qt constraints, the sequence of building widgets is
> different. What was the mainwindow becomes a normal X-window
> that I hand to Qt. The display handle is proper to TeXmacs so
> the TeXmacs events are still treated by a modified TeXmacs loop
> (see below). Progressively stuff that was handled by the native
> TeXmacs toolkit will get treated by Qt.

It is very hard for me to answer your technical questions
if I can not have a look at the complete code.
I do not see a priori what is wrong.

> I probalby attempt to repaint before the data in the widget is in a
> coherent state. So I would like to know when this state is reached.  I
> don't understand too well the flow of information to get that right.
> I get to repaint the menu, the first bar and half of the second bar
> before I hit the problem.

It is very difficult to answer this question,
because the code is very hacky on this point
(I had to struggle with X on several points,
which makes the code less natural).

> In fact I have mutilated the loop because It becomes a routine that I
> call from a Qt timer with 'delay' as interval. Is the missing code
> ( Wait for events on all channels and interpose,  Popup help balloons)
> cause of the problem?

The best advice I can give is to eliminate all superficial things first,
like waiting for computer algebra output or interrupting repainting.
This should make the flow control already a bit easier.

As to your question about the missing code, I can only suggest to
put it back again and check. You may also change the delay rates and
check whether this has an effect on the particular moment that things
go wrong.

> void
> x_display_rep::event_loop_qt () {
>   cerr << "event_loop_qt\n";
>     // Get events
>     while (XPending (dpy) > 0) {
>       cerr << ".";
>       XEvent report;
>       XNextEvent (dpy, &report);
>       // cout << "Event: " << event_name[report.type] << "\n";
>       x_window win= (x_window) Window_to_window[report.xany.window];
>       if (win!=NULL) process_event (win, &report);
>       count= 0;
>       delay= MIN_DELAY;
>       continue;
>     }
>     // Redraw invalid windows
>     iterator<Window> it= iterate (Window_to_window);
>     while (it->busy()) {
>       x_window win= (x_window) Window_to_window[it->next()];
>       win->repaint_invalid_regions();
>     }
> 
> }
> 
> 
> --
>   stef
> 
> 
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/texmacs-dev
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]