summaryrefslogtreecommitdiffstats
path: root/src/pdfquick/PdfMultiPageView.qml
Commit message (Collapse)AuthorAgeFilesLines
* Delay PdfMultiPageView.goTo[Page|Location] if called too earlyShawn Rutledge2024-01-251-0/+22
| | | | | | | | | | | | | | | | PdfMultiPageView does not expose a property alias to TableView.rows; we could call it pageCount, but we don't want to mislead users into thinking that the view is the "source of truth" for how many pages it's going to show. The document's pageCount is populated earlier, and that's a problem only in such a case when it's too early to ask the view to go to a particular page. So we work around it in the view by treating these goTo functions as requests to be satisfied as soon as it becomes possible. Fixes: QTBUG-119416 Pick-to: 6.5 6.6 6.7 Change-Id: Ie2377fe6f2983b72e871b1be2afe4d0878f60841 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Fix qmllint warnings in Qt PDF Quick componentsShawn Rutledge2024-01-251-15/+19
| | | | | | | | A few bogus warnings remain. Pick-to: 6.7 Change-Id: I0fba71f5272aa095106de9f0e382674abbde5b07 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix discontinuity with successive pinch-zoom in PdfMultiPageViewShawn Rutledge2024-01-251-1/+5
| | | | | | | | | | | | | pinch.persistentScale is settable since 6.5 (qtdeclarative a432970b258edb9ff041d221b2155df30cad4799): we need that to tell PinchHandler to start over from 1 after we have also set the rendered scale back to 1, because PinchHandler does not read the scale property for itself. Fixes: QTBUG-115502 Pick-to: 6.5 6.6 6.7 Change-Id: I21951c447bf33e5942b6a1635488d5474ec8f293 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* PdfMultiPageView: don't force TableView to rebuild from scratch on zoomShawn Rutledge2023-07-271-10/+3
| | | | | | | | | | | | | | | | | | It's behaving better now without this workaround, which was also causing TableView to iteratively pool and reuse delegates for all pages, which was causing them to actually request images for each page. But at least forceLayout() still seems to be necessary to cope with the change in cell size: as the docs say, the columnWidthProvider and rowHeightProvider functions will return different values after zooming, so TableView needs to be told to re-evaluate the size and position of each visible row. Reverts 4a08034ca3b274e0309530bed4630521b8ad91c9 Pick-to: 6.6 6.5 Fixes: QTBUG-114953 Change-Id: Id84e5359239300d1450868219fe30f402d56c3cb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Pdf[Multi|Scrollable]PageView: enforce zoom limits, don't get stuckShawn Rutledge2022-09-061-3/+4
| | | | | | | | | | | | | | Handlers must not get disabled because the zoom range is beyond limits: rather, let PinchHandler's minimumScale and maximumScale enforce them. So far, PdfMultiPageView and PdfScrollablePageView do not have other ways of zooming (like a WheelHandler for control-mouse-wheel), so we don't need BoundaryRule. But the limits applied by PinchHandler are "hard" limits: you bump up against them instantly, with no easing curve. Pick-to: 6.4 Fixes: QTBUG-104769 Change-Id: I4eb785e572816d1b80ea9c8f4f5b9c925594afac Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Doc: Fix linking issues on Qt PDF documentationTopi Reinio2022-07-051-8/+2
| | | | | | | | | | | | | These warnings were not captured by the documentation testing in CI. Fix or remove links to properties from inherited QML types, and remove \sa entries that are already linked to in the documentation. Fix incorrect \inqmlmodule argument for PdfPageImage. Pick-to: 6.4 Change-Id: If2c14d468a6dc3cd464ca4de1f4e39ad48d4d326 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-221-38/+2
| | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I869ffda1080e283f231eb0dc4477b260f2054d99 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add PdfLinkDelegate instead of link decoration style propertiesShawn Rutledge2022-06-041-31/+5
| | | | | | | | | | | | | | | | This simplifies PdfStyle somewhat. PdfLinkDelegate could still be replaced or augmented via file selectors, but we don't expect to need to, since link delegates are already non-visual. [ChangeLog][QtPDF] A PdfLinkDelegate will now be instantiated on top of each hyperlink in the PdfMultiPageView, PdfScrollablePageView and PdfPageView components, for event handling and to provide tapped() and contextMenuRequested() signals. It is non-visual by default, but can be customized, for example to draw underlines under hyperlinks if the PDF documents are not expected to have them already. Change-Id: Ib3726e7220a0c3858db564ca8d53a04625a11950 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Rename QPdfLinkModel::Role::Rect to RectangleShawn Rutledge2022-06-041-5/+5
| | | | | | | Roles are not abbreviated in general; this doesn't need to be either. Change-Id: I55a6fcbc4818d7363f1184b660948da4943c110b Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Redefine PdfSearchModel.currentResult as document-based; use PdfLinkShawn Rutledge2022-06-041-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PdfSearchModel.currentResult is now the index within the whole list of search results, rather than starting over from 0 on each page. This simplifies some code. The way that PdfMultiPageView uses PdfSearchModel, the currentPage property is read-only: it tells the page of currentResult (which we need in the view, because each page has the ability to show a current-search-result highlight shape, but only one page actually needs to show it). The controls in a viewer to iterate search results (up and down arrows in the footer) simply increment and derement currentResult; the currentPage property gets updated to tell the view which page currently holds currentResult; and the ListView highlight follows along in the sidebar too, because ListView.currentIndex is now bound to searchModel.currentResult. But in PdfScrollablePageView, we still need to bind the currentPage property, to get the currentPageBoundingPolygons property updated when we switch pages. Since that viewer only sees one page at a time, it's much more declarative to do it that way, rather than calling the invokable boundingPolygonsOnPage(int) function. Bindings get updated on their own; whereas in PdfMultiPageView it's a bit inelegant that we need to call boundingPolygonsOnPage() repeatedly, at the right times so that the highlights are never shown in the wrong places at the wrong time. It could be avoided if we had a separate per-page model object to filter the results from the main PdfSearchModel; but that would add significant API complexity, and perhaps be too confusing for anyone who tries to re-implement a QML-based viewer component. The current search result highlight now stays on the page where the user left it: scrolling manually to another page will no longer choose a current result on the new page, as it did before. This is more consistent with typical applications. A currentResultLink property is added, to make it easy to call PdfPageNavigator.jump(link), thus passing along the QPdfLink.rectangles. The same link object gets re-emitted in the PdfPageNavigator.jumped signal to tell the view to scroll in such a way as to get those rectangles visible in the viewport, via TableView.positionViewAtCell(). There are a couple of drive-by fixes: QQuickPdfSearchModel::documentChanged() doesn't need to be declared, because we are using the signal inherited from QPdfSearchModel. And const-correctness is improved in the implementation of boundingPolygonsOnPage(). [ChangeLog][QtPDF] PdfSearchModel.currentResult is now the result index within the whole set of search results rather than on currentPage; and changing currentPage no longer makes currentResult change. In the views, this means the current highlighted search result stays on the same page even when the user views a different page. Change-Id: I96957f50e703f62101b3d3c708ff5f27b162cd8d Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Use QPdfLink in PageNavigator jump() / jumped(); QML viewsShawn Rutledge2022-06-041-14/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One reason for this is to use the new tableView.positionViewAtCell(.., TableView.Contain, offset, rect) to do less scrolling when iterating search results. Now in that case, the QPdfLink object contains correct rectangles, so that we can scale the first one and pass it directly to positionViewAtCell(). When clicking a hyperlink, the destination is a point rather than a rectangle; but positionViewAtCell with a subRect works better than calling it with just an offset, so we construct a small rectangle for that purpose. It's important that the QPdfLink object emitted in the jumped() signal must not contain any rectangles in this case, so that we can distinguish a hyperlink destination from a search-result destination. The QPdfLink object from PdfLinkModel has its own rectangle, but that's the place where the user clicks. When clicked, the view calls pageNavigator.jump(page, location, zoom), rather than the jump(QPdfLink) overload, so that rectangle is not passed along. In an onJumped() handler, we expect the rectangles to be the destination, if present; otherwise we fall back to using the location property, which is always the destination, never the source. In both cases, we need to grow the destination rectangle by jumpLocationMargin, because the offset argument to positionViewAtCell() is an offset, not a margin. But since the rectangle needs to be scaled from points to pixels anyway (according to the current renderScale), it's not much more trouble to add the margin. It looks better to avoid having a search result and its highlight rectangle banging up against the corner of the viewport: the margin lets the user see a bit of context on the page, and the highlight looks more distinct by being spaced out away from the edge. And since the margin gets added to the rectangle's edges, it makes more sense to use the (qreal) point type rather than vector2d. To make it possible to emit a QPdfLink object and access its properties in QML, it's now registered as a QML type. Fixes: QTBUG-102740 Change-Id: I74ccd11a106c5e49a0ce94eef9cf2d50992923b4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Rename QQuickPdfSelection fromPoint/toPoint properties to from and toShawn Rutledge2022-06-041-2/+2
| | | | | | | It was a suggestion during API review. Change-Id: I54425bbebb90b05a2cee1cb00d51c4d61edb8784 Reviewed-by: Doris Verria <doris.verria@qt.io>
* Replace usage of currentPage with currentFrameShawn Rutledge2022-06-021-2/+2
| | | | | | | Amends 038b361c452feb41106867f20b2484c1f384b0d1 Change-Id: I417822f27d5a57749754bf043594aad8a220b63f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove PdfPageView.currentPage propertyShawn Rutledge2022-05-311-1/+1
| | | | | | | It was just an alias for currentFrame. Change-Id: Ib16f579b1905cf5fe43496553ebde054d474a7c7 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Rename QPdfNavigationStack to QPdfPageNavigator; QML type tooShawn Rutledge2022-05-271-25/+25
| | | | | | | | | | | | | | | | | 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>
* PdfMultiPageView: fix PdfNavigationStack.onJumped horizontal scrollingShawn Rutledge2022-04-221-3/+1
| | | | | | | | | | | | | | | xOffsetLimit should not be divided by 2: it's meant to be the farthest that we can scroll to the right without going beyond the page edge. Since we still have the tableView.rebuild() workaround function, remove some calls to forceLayout() that seem not to help with anything, but just caused a warning: Cannot do an immediate re-layout during an ongoing layout! Pick-to: 6.3 Fixes: QTBUG-102742 Change-Id: I57f419467e01fc92c12e5d74262d8fa878ce1c79 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* PdfMultiPageView: re-layout when size changesShawn Rutledge2022-04-221-0/+2
| | | | | | Fixes: QTBUG-102746 Change-Id: I75528f86a2c8b3d61f73929ea64a1ce2f5e54167 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* PdfQuick: deal with loading a different documentShawn Rutledge2022-04-121-0/+8
| | | | | | | | | When loading a new document, clear the navigation stack, reset the view to the upper-left corner, and clear the special device in PdfPageImage. Task-number: QTBUG-102294 Change-Id: I275b46f8958d4e8abe3814c1f358df5969c36d4d Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* doc: fix QtPDF doc warnings and mistakesShawn Rutledge2022-04-081-3/+3
| | | | | Change-Id: Id2ce2bd8852c4051edd29bf474bac216ba14f2b5 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Move QQuickPdfNavStack core into QPdfNavigationStack; use in QPdfViewShawn Rutledge2022-04-081-12/+17
| | | | | | | | | | | | | | | 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>
* doc: begin adding docs for MultiPageView component and exampleShawn Rutledge2022-04-071-7/+222
| | | | | | | Pick-to: 6.3 Task-number: QTBUG-81560 Change-Id: I062e022a97c146e9a746b6d6358868bfe0c0a7d7 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QtPdf: hide "debug" properties; qt.pdf.(single|multi]pageview log catsShawn Rutledge2022-03-161-19/+17
| | | | | | | | | | | | | The property "debug" was not nice API, but I have not gotten in the habit of using logging categories from QML. This is much nicer. The "debug" property is still useful to turn on some visual debugging features, but it's better to hide it rather than keeping it exposed and needing to document it. Pick-to: 6.3 Change-Id: I5ec4156e6d4e7ccd0f406fe62ee810f4401561ec Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* multipage PDF viewer example: simplify, and fix more qmllint warningsShawn Rutledge2022-03-101-1/+1
| | | | | | | | | | - no need for the document.onStatusChanged handler - no need for empty-argument function() { ... } in onSignal handlers - unqualified access and so on - scale the search field margins and erase-button a bit better Change-Id: Ice8a41e4cc1fb0385046aa1867fdb4b1400234b6 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QtQuick.Pdf: fix rendering on high-dpi screensShawn Rutledge2022-03-071-1/+1
| | | | | | | | | | Default scale is 1 point = 1 pixel, but that means logical pixels, since we have that facade everywhere else in Qt. We use image.sourceSize to make it render more pixels than it otherwise would, according to devicePixelRatio. Change-Id: I3ff05f050c9b60c14b8208d61717e796ddd56220 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Multipage PDF viewer: use TableView.columnWidthProviderShawn Rutledge2022-03-071-3/+2
| | | | | | | This doesn't actually fix anything AFAICT. Change-Id: Id5a20a409ae1f6d2e992221dd22bef2c3ddf9200 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Multipage PDF viewer: fix horizontal scrollingShawn Rutledge2022-03-071-1/+1
| | | | | | | | The ?? operator has lower precedence than *, apparently, so we need parens. Amends 170fc1c2cb43318817552f1a1bed42b5cdc6eb36 Change-Id: I0ff2c7ce408043e7a1d3f862dd3e591c9bea5336 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add QQuickPdfPageImage and use in the PDF viewer componentsShawn Rutledge2022-03-031-5/+5
| | | | | | | | | | | | | | | | | | | | | | | Image works fine, except that if QPdfIOHandler is not given an already-allocated QPdfDocument instance, it needs to construct its own. So we now have QPdfFile: a subclass of QFile acting as a wrapper, to carry the document instance (that the user has most likely declared) down into QPdfIOHandler::load(QIODevice *). Thus, in nontrivial PDF-viewing use cases, there is now usually only one multi-purpose document instance. And this takes care of viewing password-protected PDFs in the multipage example, because we already prompt for it and set the document.password property. In trivial use cases, it's OK to continue using Image, and QPdfIOHandler will still construct its own QPdfDocument instance if the QIODevice cannot be cast to a QPdfFile. Task-number: QTBUG-77506 Task-number: QTBUG-83988 Task-number: QTBUG-96574 Change-Id: I3adfa54c30b0baa5dedebcf3bc759758f136b757 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtPdf: fix qml issuesShawn Rutledge2022-02-221-8/+10
| | | | | | | | | | | | | - required properties - unused imports - nullish coalescing - issues found by qmllint (despite all the noise) Reverts 99db09404787901647213abceda74befc7efa8f1 Task-number: QTBUG-82873 Change-Id: I0042d2eaeacba58adcf280c37b9668f8d76d0f93 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QtPDF QML: replace var with const where possibleShawn Rutledge2022-02-221-28/+27
| | | | | Change-Id: I63b0602bb3bb7161b87da2d8378b17b47dd872c5 Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
* Make QtPdf a proper generated moduleShawn Rutledge2022-02-221-0/+432
- remove plugins.qmltypes, because it's generated automatically since d32563a3365fd9432993590e6ac9817fe6f6bd41 - plugin code is also generated, so we don't need plugin-related CMake commands - QtQuick is a dependency; auto means forward the import version to the dependency. - QtQuick.Controls is only needed in bundled qml files, and we expect tooling to find it from import statements. It's not declared as a cmake dependency because we don't use it from C++. - move qml files into the source directory so that the implicit import matches the module directory - move style-specific PdfStyle.qml files into directories beginning with capital letters, since we are moving them anyway, and the styles now have capitalized names Change-Id: If517ce30d0e22fb0354272cd2002841fd2783cfc Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>