-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[office] Add regression tests for PDFDocumentPage. #101
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -27,6 +27,12 @@ import "PDFStorage.js" as PDFStorage | |
DocumentPage { | ||
id: base | ||
|
||
// Group of accessors properties. Can be used to control the PDFDocumentPage | ||
// from outside or for testing purposes. | ||
property alias document: pdfDocument | ||
property alias placeHolder: placeHolderLoader | ||
property alias toolbar: toolbar | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Commonly not fond of adding very much code used only for testing, but can have some. Just thinking it could be marked for such usage so it's not accidentally removed as cleanup. Maybe could also have all testability properties of the file grouped together? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I try to tune the tests so added accessors may have a sense from a public API point of view, like exposing the toolbar item so any external user of the PDFDocumentPage item may control better the toolbar behaviour for their own needs. Well, for the moment, I've simply added a comment on every added accessors… |
||
property var _settings // Handle save and restore the view settings using PDFStorage | ||
property ContextMenu contextMenuLinks | ||
property ContextMenu contextMenuText | ||
|
@@ -90,6 +96,7 @@ DocumentPage { | |
} | ||
|
||
Loader { | ||
id: placeHolderLoader | ||
parent: base | ||
sourceComponent: (pdfDocument.failure || pdfDocument.locked) ? placeholderComponent : null | ||
anchors.verticalCenter: parent.verticalCenter | ||
|
@@ -171,6 +178,11 @@ DocumentPage { | |
|
||
property Notification notice | ||
|
||
// Group of accessors properties. Can be used to control the toolbar | ||
// from outside or for testing purposes. | ||
property alias searchIconized: search.iconized | ||
property alias searchText: search.text | ||
|
||
width: parent.width | ||
height: base.orientation == Orientation.Portrait | ||
|| base.orientation == Orientation.InvertedPortrait | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default case leaks memory? Should warn? Could also note code changes in commit message and why they were done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this is dirty fallback solution for the following issue:
In that situation you may have some rendering job in the queue before the document is unlocked, which segfault later in pdfjob.cpp#61 when calling page() on a non-existing one.
What do you think ? Is it better to try to cure this race condition, that doesn't happen in practice because we're not reusing the same PdfDocument instance each time ; or should I add a comment here mentioning the reason ?
Besides, writing this, I notice that I should convert the Q_ASSERT() I've added in pdfjob.cpp#61 as a return statement for the same race condition reason with a document smaller than the previous one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For things that cannot happen in normal operation of the application I wouldn't mind if there are small workarounds avoiding wrong behavior in testing. However, those should be clearly marked with comments, maybe even doing qWarning(), so it's possible to catch the problem if application behavior ever changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've added a comment before the test. I've also added some qWarning() in pdfjob.cpp to signal something unusual happening (and avoid segfaults also).