| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to call PdfPageNavigator.jump(link) when a link is clicked;
therefore PdfLinkModel needs to provide this object; therefore it makes
sense to store the links as QPdfLink instances, and get rid of the
redundant internal Link object type. But QPdfLink did not have storage
for a QUrl until now. The textStart and textCharCount fields sounded
useful, but in practice were set and not used.
QPdfLink gains toString() and copyToClipboard() methods.
Also removed some unused cruft in qquickpdflinkmodel.
[ChangeLog][QtPDF] PdfLinkModel now provides a QPdfLink object for each
link. QPdfLink now contains everything necessary to render delegates for
links and search results, and handle clicking links; and there is a
copyToClipboard() method for use in context menus, which will copy
the text returned trom toString(), which is also invokable.
Change-Id: Ifa5abe6df8f8d6f9ef98971044c26691ec4b9a36
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
Inheritance was a decent way to model this, conceptually. A hyperlink
is modeled like the HTML kind: a region covering the source material
that the user will click on, and a destination where we will jump when
they click it; whereas a search result has the same information plus the
text before and after the search text, so that we can show some context
in a ListView with search results.
By going this way, we need to document which fields we use which way
under which conditions. But, we have a rule that value types cannot use
inheritance, just in case the user would ever try to use them
polymorphically (in spite of the other rule that we never pass value
types by pointer, and thus there is no actual polymorphism), or just
in case the destructor of the base class would not be called when
a subclass value goes out of scope.
Anyway, perhaps an upside is that this resembles a link in Xanadu, or in
a fully-normalized database schema: an object that fully describes both
ends of a connection, and thus is able to traverse either direction, in
theory. (Although we don't really use it that way. The link-following
behavior in a PDF viewer tends to be one-way, as in a web browser.)
When using QAbstractItemModel (as in QPdfSearchModel and QPdfLinkModel),
the cells in the "database" are accessed separately via the data()
function, so there is no need for a transport object to hold a whole
"row". That's OK for item views; but we need this link object for the
purpose of less-clumsy C++ API, as a return value from a few functions.
For example when implementing a viewer in QML, we use Repeater to
instantiate Items for each hyperlink (decorations and a TapHandler),
and Repeater uses the QAIM interface. But when implementing a
widget-based viewer, it's better to call a hit-testing function like
QPdfLinkModel::linkAt(pos) to find out whether a link exists at a
particular mouse location; and that function can return a QPdfLink.
In this case, the link will not contain contextBefore and contextAfter,
because the viewer doesn't need them, and it's difficult to find this
text in the PDF model. But QPdfSearchModel::resultsOnPage() and
reultAtIndex() return link objects that do contain the context strings.
We don't expect users to have made much use of these classes in C++
so far, because we prioritized QML API (which this change does not
affect), and did not yet document how to use QPdfSearchModel and
QPdfLinkModel in widget-based viewers.
Fixes: QTBUG-98886
Change-Id: Ie68f9b893a342d145abac0b143e9254827c70bd7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
