| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Value classes should not be exported wholesale, because that makes
inline function part of the ABI on Windows debug builds, severely
restricting what we can do to them going forward (e.g. removing).
De-inline the QPdfSearchResult dtor as a drive-by.
Fixes: QTBUG-98885
Pick-to: 6.3
Change-Id: If2a2c7bec2b99df7e33dfc008fd07e6edda5413c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
The ctor is a perfect sink for the arguments, and already took them by
value. What was missing was to std::move them into place instead of
using the copy ctor.
Change-Id: I3a708bea2cdd8417ea3e604af2850d99a5966c3f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
|
|
|
|
|
|
| |
Remove usages of outdated LGPL3 header that references LICENSES.LGPLv3
instead of LICENSES.LGPL3. For the examples, use BSD.
Change-Id: I1fae49110160c1183327ec54c9dc447c69588a65
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
|
|
|
|
| |
Task-number: QTBUG-84469
Change-Id: I666a060351f73783e15e3f96884c9393a5cd7e46
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
...as separate roles, to make alignment easier, and to avoid hard-coding
HTML tags in the Context role as it was before.
But the strings in these context roles are not always adjacent to the
search results in geometric coordinates sometimes, in some PDF files,
despite having adjacent character indices. I.e. the "next" character
after the search string, or the "previous" character before it, could be
anywhere on the page.
Change-Id: Ief0a490b64fdb3c3ca98506926650648b609ece1
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
It's a QAbstractListModel, so now PdfMultiPageView has a ListView in a
left-side Drawer showing all results found so far.
- In PdfMultiPageView, multiple pages exist at once, so it makes sense
to use the same searchmodel for all.
- It's faster and saves memory.
- Search results on each page can be cached.
- It's possible to show search results in a ListView or QListView.
Change-Id: I66fba6975954a09a4d23262be87ff8cc25ee7478
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
