Split single QTextEdit into several QGraphicsProxyWidget

[Toniy]

I'm developing a text editor which shows pages in LibreOffice's manner (e.g. on solid background with space between pages).

So, there is one sample of QTextDocument (http://doc.qt.io/qt-4.8/qtextdocument.html) and several samples of QTextEdit (http://doc.qt.io/qt-4.8/qtextedit.html) (depending on page count) scrolled to certain page with QTextEdit::verticalScrollBar()->setValue(int). I place each QTextEdit on QGraphicsScene (http://doc.qt.io/qt-4.8/qgraphicsscene.html) with QGraphicsProxyWidget (http://doc.qt.io/qt-4.8/qgraphicsproxywidget.html).

Is that manner of QTextDocument handling redundant? Is there way to place one QTextEdit on several QGraphicsProxyWidgets (one page on each proxy widget)? E.g. if document has one page then one proxy widget occurs, if it has two pages then QTextEdit gets longer instead of scrolling and second page's content appears on second page and so on. Or my solution is only way due to limitations that Qt makes?

I have found this post (http://www.qtcentre.org/threads/14918-Paint-QTextDocument-splitted-by-pages-1-5-and-edit-txt?p=297890&highlight=#post297890) but due to expiring of source code attached in one of its replies I can't be sure that this is definitely that I need.

[anda_skoa]

That doesn't sound like a good use case for a widget in a graphics item proxy.

I would recommend investigating how QTextEdit draws part of the text and then implement your page items that work on the same QTextDocument, each drawing "its" page.

Cheers,
_

[Toniy]

Thanks for reply.

You mean to implement my own QTextEdit-like widget without scrolling, don't you?


That doesn't sound like a good use case for a widget in a graphics item proxy

For better understanding of situation: what certainly isn't good in that use case?

[anda_skoa]

You mean to implement my own QTextEdit-like widget without scrolling, don't you?

My interpretation of your goal is that you want the graphicsview to be the scrollable area, with one item per page of the document.
So you wouldn't need a widget at all (that's the graphicsview), but "page" items to put into the view's scene.



For better understanding of situation: what certainly isn't good in that use case?

These are bascially hacks to take an existing widget into a graphicsscene, e.g. buttons or comboboxes.
Widgets weren't designed to be embedded into such a situation, the proxy tries its best but sometimes things don't work that well.

Wouldn't use it for a complex control such as a text edit unless absolutely necessary.

Cheers,
_

[Toniy]

but "page" items to put into the view's scene

So, it is sufficient for my "page" item to be a subclass of QGraphicsItem (http://doc.qt.io/qt-4.8/qgraphicsitem.html), isn't it?
If so then next question occurs: do I understand correct that all low-level text editing functions like placing text on page, keeping line spacings, painting tables and so on must be implemented by me?

Explanation for proxy widget is undestood, thanks.

[anda_skoa]

So, it is sufficient for my "page" item to be a subclass of QGraphicsItem (http://doc.qt.io/qt-4.8/qgraphicsitem.html), isn't it?

Yes, that would be my guess



If so then next question occurs: do I understand correct that all low-level text editing functions like placing text on page, keeping line spacings, painting tables and so on must be implemented by me?

Well, text model modification and rendering can likely be delegated to QTextDocument, like QTextEdit would do itself.
You'll have to do the input handling of course.

Might also be worth to look into how other Qt based page oriented editing applications handle this, e.g. Calligra Words or Stage: https://cgit.kde.org/calligra.git/tree/

Cheers,
_

[Toniy]

Thanks for replies, direction of thinking becomes much more clear.


You'll have to do the input handling of course.

Do I understand correct that input handling (besides scrolling) is only thing that QTextEdit does on its own?

[anda_skoa]

You'll have to look at the code.
Either locally or through the great code browser at Woboq.org (https://code.woboq.org)

Cheers,
_