[Interest] Embedding a QTextBrowser in a QML application: QObject: Cannot create children for a parent that is in a different thread
Shawn.Rutledge at qt.io
Wed Mar 30 10:53:39 CEST 2022
On 2022 Mar 30, at 03:03, Jeffrey Brendecke <jeffrey.brendecke at gmail.com<mailto:jeffrey.brendecke at gmail.com>> wrote:
For an app I am working on I need a component for displaying HTML rich text. TextEdit does not provide an important feature I need present in QTextEdit and QTextBrowser: scrollToAnchor( const QString& ).
So you went and wrote up a feature request at bugreports.qt.io<http://bugreports.qt.io> about that, first thing, right? ;-) Please do, because we know that Qt Quick cannot be taken seriously for desktop development unless we add missing features like this over time; and that’s really a goal.
Since TextEdit doesn’t have scrolling built-in (the separation of concerns principle was followed there at least), you’d need to put it in a Flickable, and then you’d need a way to find the y coordinate of the anchor location so that you can set Flickable’s contentY. And we don’t have API for dealing with anchors AFAIK. Probably we should, but it needs a bit of brainstorming about what that should look like; e.g. we could have a function to look up the position by name, like anchorPosition(string); but maybe you first need a list of anchors. (Even the name could be a matter for discussion since “anchors” usually mean something different in Qt Quick.) If you are getting a list, should it be only a QStringList or should we provide all the necessary information at once, somehow? QVariantList? Or would a QAIM be useful? Something like https://code.qt.io/cgit/qt/qtwebengine.git/tree/src/pdf/qpdflinkmodel_p.h but maybe that’s overkill for this case. Anyway if you wanted to show a sidebar with a “table of contents” or list of link destinations (ListView or TreeView?) some sort of model would be useful. (I will soon try to use TreeView in QtPDF, although in that context, links and bookmarks are different things.) Even better if the same model could be used both in Quick and widget-based applications; maybe it could be done if it would work only with QTextDocument and QTextLayout objects, and the view’s job is to keep it updated whenever the text layout is done or redone; but I’m not sure. Having complete information about anchors and their locations at startup would be in conflict with the idea of doing text layout lazily, to save time and memory when the text is large (like a document containing a whole book).
Does anybody have any better ideas?
The app will have to work on iOS, so WebEngine is out of the question, and I would not want to have all the overhead of having a web browser in the app anyways.
Given the text itself is fairly simple (no images, just formatted text), QTextBrowser gives me what I need.
I have been looking into trying to embed a QTextBrowser into a QML application using the approach in this project:
A similar approach is used here:
Data visualization with QPainter… <shudder> I guess they don’t expect real-time…
* Creating a class deriving from QQuickPaintedItem
* Encapsulating an instance of QTextBrowser instantiated with a nullptr parent as a member in that class
* Rendering from the QTextBrowser into the QQuickPaintedItem derivative
* Hooking up the necessary events between the QQuickPaintedItem and the QTextBrowser instance
That all seems to be no problem. The problem I get results in a segmentation fault:
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QTextDocument(0x5617e2ebed80), parent's thread is QThread(0x5617e2958860), current thread is QSGRenderThread(0x5617e2d18400)
I’d have to use the debugger to understand what threads are involved and where is this child being created from, but yes thread ownership of objects is a thing. https://doc.qt.io/qt-6/qobject.html#moveToThread or try to figure out how to get the child creation into the correct thread, or...
You could alternatively go the other way around: write a widget application and use QQuickWidget for the Quick contents. (Hopefully only one of those.) And perhaps run into different bugs… but we are porting QQuickWidget to RHI for 6.4, and hopefully looking at some old bugs there while we’re at it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest