[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Qt port problem
From: |
Stéphane Payrard |
Subject: |
Re: [Texmacs-dev] Qt port problem |
Date: |
Fri, 13 Sep 2002 22:00:46 -0400 |
User-agent: |
Mutt/1.4i |
On (13/09/02 18:09), Joris van der Hoeven wrote:
> From: Joris van der Hoeven <address@hidden>
> To: address@hidden
> Subject: Re: [Texmacs-dev] Qt port problem
> Reply-To: address@hidden
> 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).
using XSynchronize() and doing a return, I get everything working but
the editor widget. So I need to figure out when it is correctly
initialized to display it.
>
> > 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