[PyQt] More QPlainTextEdit weirdness! (was: Missing scrollbar signal...)

[Sundance]

On Friday 11 December 2009 07:28:27 Henning Schröder wrote:

> I have looked at the source of QPlainTextEdit and QTextEdit. Actually the
> implementations are not consistent.
> QPlainTextEdit calls verticalBar.blockSignals(True) before it call setValue
> which would otherwise emit valueChanged.

Hi guys, hi Henning,

This is what's awesome about this mailing-list: you bring up the most obscure 
issue, and there's someone with a helpful and interesting answer for you. 
Brilliant!

In my case I worked around the problem by sending the signal manually after 
calling triggerAction(). Not very clean, but that's workarounds for you.

But in the meanwhile more QPlainTextEdit weirdness crept up.

As part of a helpful little feature that shows you the bottom of your text in 
a split screen while you scroll back, I use the awesome 
QTextDocument.drawContents() method. In short, you feed it a QPainter and a 
QRectF and it does what it says on the label: a slice of your document as 
delineated by the QRectF is rendered onto the QPainter.

There is, as far as I can tell, no difference between the QTextDocument 
returned by QTextEdit.document() and QPlainTextEdit.document(). Same class in 
both cases.

And yet in the latter case, drawContents() renders nothing at all. Cursory 
investigation points to a different QAbstractTextDocumentLayout implementation 
under the hood depending on the TextEdit flavor in use.

So I think I'm going to drop QPlainTextEdit entirely, even though in theory 
it's better suited to my problem domain. After a few tests, the benefits in 
speed and memory usage are not obvious anyway. (Which is possibly a testament 
to QTextEdit's efficiency, when you think of it.)

But alternative viewpoints would be welcome!

Bye,

-- S.