[Top][All Lists]

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

[Texmacs-dev] Re: Experimental Qt port

From: Abdelrazak Younes
Subject: [Texmacs-dev] Re: Experimental Qt port
Date: Fri, 03 Oct 2008 14:55:14 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080918110343 Shredder/3.0b1pre

On 03/10/2008 14:32, address@hidden wrote:

On Oct 3, 2008, at 2:14 PM, Abdelrazak Younes wrote:

On 03/10/2008 11:59, address@hidden wrote:

On Oct 3, 2008, at 10:14 AM, Abdelrazak Younes wrote:

On 02/10/2008 14:53, address@hidden wrote:
I've done some testing on current cvs texmacs and the situation is the

- linking with qt4.4.3 release version leads to crash (gdb session
attached below).
- linking with qt4.4.3 debug version works fine
- linking with qt4.3.5 debug or release works fine

So current hypothesis is that it is a problem with the release version
of 4.4.3. Moreover I just commited some patches which should allow
correct visualization of characters under Linux (at least for me works
on Red Hat Enterprise with Linux 2.6.9-78.0.1.ELsmp)

The problem is that a statusbar update is asked while in a paint event (see relevant backtrace snippet below). Older version of Qt did not complained but Qt4.4 changed the way child widgets are painted. We had the same crash in LyX when Qt4.4 was released. The solution was simply to remove the statusbar update call in the paint event. As a general rule, don't do any painting (even onto a pixmap) inside a paint event.

Hope this helps,

#58 0x00bae4b5 in QWidget::repaint (this=0x93aec10, address@hidden) at painting/qbackingstore.cpp:1140 #59 0x00a342c5 in QWidget::repaint (this=0x93aec10) at kernel/qwidget.cpp:8933 #60 0x00df44b6 in QStatusBar::reformat (this=0x93aec10) at widgets/qstatusbar.cpp:530
#61 0x00df4d6a in QStatusBar::event (this=0x93aec10, e=0x9726e48) at

Thanks Abdelrazak. But I cannot see where I violate the rule you are suggesting. status bar updates are issued outside paint events (as far as I can see with gdb) and I also tried to remove them without success.

Weird... But I am pretty sure that the status bar is guilty here.

I agree something strange is going on I will indagate further.

Moreover it is really strange that the program works with the debug version and not with the release one, without giving warning.

The event in question might be delayed in debug mode so that this bug is not triggered.

This could be true.

Could you point me to some relevant documentation about this issue (trolltech docs or mailing list posts...).

There is our bug report which contains a number of link to other bug reports and discussion:


I really do not undertand but it is clear that the current status of the port is very instable under Linux (at least with Q4.4/release). Alvaro is experiencing another type of crash but I think that his is related to some problems with 64 bits.

What is the build system ogf TeXMacs? If CMake, scons or QMake, I can try to compile it under Windows...

uses plain configure/make, it should work under mingw but I'm not sure.

Then I won't try, autotools in mingw/msys is a mess. We switched away from it for LyX purpose and we just use MSVC2008.

Joris know better the status of the WIndows code (for the moment Qt is responsible only for GUI, pipes and signals are managed internally by TeXmacs).

I retrieved now the cvs version.


PS: I put back the list in copy because you mentioned Joris.

reply via email to

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