[Kde-perl] Couple of problems with Qt::TextEdit - one serious

Rich kde-perl@mail.kde.org
Tue, 4 Mar 2003 11:47:58 +0000


On Monday 03 Mar 2003 8:47 pm, Germain Garand wrote:
> Le Lundi 03 Mars 2003 15:47, Rich a =E9crit :
> > Hi everyone
>
> Hello,
>
> > I've got one non-serious and one deadly problem with Qt::TextEdit.
> >
> > 1) Appending text to textedit widgets in "log viewer" mode in Qt3.1x
> > causes a spurious new line to get added between each text chunk. I've
> > looked at the archive from a recent discussion:
> >
> >   http://lists.kde.org/?l=3Dkde-perl&m=3D104525628210582&w=3D2
> >
> > So, am I correct in assuming this is a PerlQt issue that is known abo=
ut?
>
> err... no I think not.
> As said in the message you link to, It's the normal Qt behaviour.
> QTextEdit::append() adds a new paragraph to the text ( for simple and
> richtext, since v3.0.5.), hence the newline.
> I'm not very familiar with QTextEdit, but it seems you need to set the
> whole text at once each time you add a line to avoid the creation of a =
new
> paragraph (at least that's what I did for pqtsh).
>
> Their might be other solutions, I don't know.

Ok, sorry about that.=20

Typical, I'm writing a log viewing app - Qt provides a new Log viewer mod=
e=20
that works excellently but adds a few quirks for good measure :) I'll hac=
k=20
the newline off the end of each chunk instead then!

I can't really add the text in one go sadly - on slower machines there's =
a=20
substantial delay (10, 20, 30 secs...) after calling setText with a big c=
hunk=20
of text before the text gets displayed. To get round that I'm appending 1=
28K=20
chunks and using a progress dialog to let folks cancel if need be.

Never mind, I still like Qt :)

> > 2) I can blow Qt up with ease:
> >
> > ############################################################
> >
> > use strict;
> >
> > use Qt;
> >
> > my $app    =3D Qt::Application(\@ARGV);
> > my $widget =3D Qt::TextEdit;
> > my $string =3D "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n" x 1000=
00;
> >
> > {
> >   use bytes ();
> >
> >   print "Displayed text size: ", bytes::length($string), "\n";
> > }
> >
> > $widget->resize(600,480);
> > $widget->setText($string);
> >
> > $app->setMainWidget($widget);
> >
> > $widget->show;
> >
> > $app->exec;
> >
> > ############################################################
> >
> > If I run the above, right click and choose "Select all" the app crash=
es
> > with the message "Broken pipe". I've tried this with perl 5.8, PerlQt
> > 3.006, Qt3.0.5 and Qt3.1.1 with Mandrake and SuSE and the behaviour i=
s
> > the same.
>
> I get the exact same result with  C++ source code on a Duron 800 MHz /
> 384Mb, so no, that's not related to PerlQt...
>
> mmh wait... looking closer, it really looks like the culprit is KDE's
> klipper that doesn't like having to deal with a 4 Megs selection. Or th=
e X
> clipboard, maybe.
>
> If I suppress it from kicker, everything is fine... then if I add it wh=
ile
> the text is selected, the mysterious pipe strike again...

Yes, I've just killed klipper and it works fine now - I'm guessing its no=
t an=20
X clipboard problem as I can select and copy a 20Meg chunk of text with t=
he=20
Red Hat log viewer which is a Python/GTk app.

I'll file a bug report to the klipper folks - thanks for finding the real=
=20
culprit so quickly.
--=20
Rich
scriptyrich@yahoo.co.uk