| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might reduce some confusion about the fact that the back/forward
"stack" isn't strictly a stack in the data structure sense: it's more
like QUndoStack. It causes a QML source incompatibility relative to
Qt 5, but keeps the C++ class name the same as it has been in QtPdf for
a long time. Amends 3ad445f9f24a9d3f259ed1781460a63346a728e4
[ChangeLog][QtPDF] The PdfNavigationStack QML type has been renamed to
PdfPageNavigator, matching the C++ type QPdfPageNavigator. These
remember navigation history within a document, and are helpful to
implement back/forward buttons similar to those on a web browser
in both Qt Quick and widget-based viewer applications.
Change-Id: Id8dc17aa416bb7064b1f0f300a47c07c83b7f47e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickPdfNavigationStack was implemented independently until now, but
users will need the same functionality in widget-based PDF viewers.
QPdfPageNavigation on the other hand may have eventually had the same
aspiration, but was just a glorified up/down counter thus far, with
questionable API; so we get rid of it, and make the API for page
navigation as much the same as possible between Quick and Widgets.
We rename push() to jump() along with removing the emitJumped argument.
Now jump() always emits (so we have to be more careful when to call it).
Change-Id: Icb07158a351e29b81e58ec037cd323bc0f54a1a1
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
Pins vtable to a single TU, instead of duplicating it across all TUs
that use the class, possibly causing invalid dynamic_cast<>s and other
bugs.
Fixes: QTBUG-98880
Task-number: QTBUG-45582
Change-Id: Ic296f4583097181ac4d824fac6dab4671ae14a50
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: Ifa2914e7bca9c224670a1891785d0ba8262cd61b
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
Port QtPdf to Qt6:
* QtPdf,QtPdfWidgets,QtPdfQuick libs
* QtPdfQuickPlugin, QtPdfPlugin (imageformat) plugins
* widget and quick examples
* qtpdf tests
To fit gn cmake integration and new repo layout code is a bit
reshuffled.
Compared to qmke build following features are not ported yet:
* ios fat libs
* qtbase 3rdparty static dependencies
WebEngine build can be skipped with setting
QT_FEATURE_qtwebengine_build=OFF
Note this patch needs follow up for 6.2 branch to disable qtpdf
builds by default, since this should not part of qt 6.2 release.
Pick-to: 6.2
Task-number: QTBUG-95353
Change-Id: I4dd9f3934bdd478fb6d2fa686074a24d91f09953
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
