D18238: Implements a new button on findbar that allows users to choose the color that highlights the text
joaonetto marked an inline comment as done. joaonetto added a comment. There's some people asking for it on bugzilla, to change the search highlight color, but as Nate said, no other reader does this. 384267 Also mentions this of "Selection Background", but would it change highlight color too or only the string that I'm searching? INLINE COMMENTS > aacid wrote in searchlineedit.cpp:92 > why does setting the color start a new search? So the rect changes color. I think that continueSearch would be better. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18238 To: joaonetto, #okular Cc: ngraham, aacid, okular-devel, tfella, darcyshen
[okular] [Bug 237014] Find tool when text has been highlighted
https://bugs.kde.org/show_bug.cgi?id=237014 Nate Graham changed: What|Removed |Added CC||n...@kde.org -- You are receiving this mail because: You are the assignee for the bug.
D18238: Implements a new button on findbar that allows users to choose the color that highlights the text
ngraham added a comment. I'm not really sold either. No other app has this setting. It seems like one of the major reasons why we have a color scheme and color chooser system is precisely so individual apps don't have to implement features like these themselves. I'm sure we can come up with a cleverer way to fix 237014 besides simply adding another configuration option. It's not as bad as it used to be since the search highlight now has a box around it. But maybe the bug here is that we're not using a color from the color scheme for highlighting search results. Kate uses the "Selection Background" color to highlight search results and it works okay. Can we not do this in Okular because it could conflict with the actual selection color because you can have text selected and search results highlighted at the same time? What if we used the "Selection Background" color but tinted it differently for each one? Or maybe we could use a different shade of yellow for the highlight annotation's default yellow color? REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18238 To: joaonetto, #okular Cc: ngraham, aacid, okular-devel, tfella, darcyshen
D18238: Implements a new button on findbar that allows users to choose the color that highlights the text
aacid added a comment. If you move it to the config dialog i guess it may make sense to have if it's not very intrusive. You forgot about presentationsearchbar.cpp And if you really want to let change this yellow, you may also let people want to change the blue when searching on the thumbnail? As you may notice I'm really not sold on this extra configuration option :D Someone else has opinions on this? INLINE COMMENTS > okular.kcfg:310 > + > + Qt::yellow > + Let it be the same color it was, i.e. qRgb( 255, 255, 64 > searchlineedit.cpp:92 > m_changed = true; > +startSearch(); > } why does setting the color start a new search? REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18238 To: joaonetto, #okular Cc: aacid, okular-devel, tfella, ngraham, darcyshen
D18283: Auto-expand all tree elements in the side panel when the panel is first shown
joaonetto updated this revision to Diff 49587. joaonetto added a comment. Updated files REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D18283?vs=49586=49587 BRANCH master REVISION DETAIL https://phabricator.kde.org/D18283 AFFECTED FILES part.cpp ui/side_reviews.cpp ui/side_reviews.h To: joaonetto Cc: aacid, okular-devel, tfella, ngraham, darcyshen
D18283: Auto-expand all tree elements in the side panel when the panel is first shown
joaonetto added a comment. Fixing it, other files went in. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18283 To: joaonetto Cc: aacid, okular-devel, tfella, ngraham, darcyshen
D18283: Auto-expand all tree elements in the side panel when the panel is first shown
aacid added inline comments. INLINE COMMENTS > okular.kcfg:309 > > + > + Qt::yellow This seems to have sneaked form a different changeset. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18283 To: joaonetto Cc: aacid, okular-devel, tfella, ngraham, darcyshen
D18144: Implemented find function from console
aacid added a comment.
Please make sure you configure your text editor to not change whitespaces,
there's lots of unneeded whitespace changes that we don't want.
INLINE COMMENTS
> part.cpp:1602
> +// Tries to find the text passed from terminal after the file is open
> +findTextOnStartUp();
> }
just move the code of the function here, it's three lines and makes it clearer
it's something we only do here.
> part.cpp:3631
> +delete m_textToFindOnOpen;
> +
> +}
This won't matter since i asked you to move m_textToFindOnOpen to be just a
QString, but ehre you had a bug, you needed to reset m_textToFindOnOpen to
nullptr after delete;
> part.h:413
> +// String to search in document startup
> +QString *m_textToFindOnOpen = nullptr;
> +
This should just be a QString, not a QString *, set to it QString() when
clearing it for "already searched"
> shellutils.cpp:81
> {
> -return
> QStringLiteral("%1:%2:%3:%4:%5:%6").arg(startInPresentation).arg(showPrintDialog).arg(showPrintDialogAndExit).arg(unique).arg(noRaise).arg(page);
> +return
> QStringLiteral("%1:%2:%3:%4:%5:%6:%7").arg(startInPresentation).arg(showPrintDialog).arg(showPrintDialogAndExit).arg(unique).arg(noRaise).arg(page).arg(find);
> }
There is a problem here when find contains a :
that is, if you do
okular https://bugs.freedesktop.org/attachment.cgi?id=140739 -find "ate: "
it will fail because when it goes to deserialize it it has "too many" :
So you need to encode it here and deserialize it properly on unserializeOptions
> findbar.cpp:200
>
> +void FindBar::findTextOnStartUp(const QString & findText)
> +{
This doesn't really have much to do with findTextOnStartup, other than "it's
the only place it's used for now"
But the function should be something more like "startSearch"
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18144
To: joaonetto, #okular
Cc: ngraham, aacid, yurchor, okular-devel, tfella, darcyshen
D18283: Auto-expand all tree elements in the side panel when the panel is first shown
joaonetto created this revision. joaonetto added a project: Okular. joaonetto requested review of this revision. REVISION SUMMARY When document is open, all the reviews are expanded in full form Bug: REPOSITORY R223 Okular BRANCH master REVISION DETAIL https://phabricator.kde.org/D18283 AFFECTED FILES conf/okular.kcfg part.cpp ui/findbar.cpp ui/findbar.h ui/searchlineedit.cpp ui/side_reviews.cpp ui/side_reviews.h To: joaonetto Cc: okular-devel, tfella, ngraham, darcyshen, aacid
D18179: PDF: Implement scaling for non-rasterized printing
aacid added a comment.
We would need a @since marker for the enum and for the new methods and a
// TODO merge with function above when a BIC change happens somehwere else
would also make sense
INLINE COMMENTS
> fileprinter.h:58
> + */
> +enum ScaleMode { FitToPrintArea, None };
> +
if this is going to be flags, it should be like this
enum ScaleMode {
None = 0,
FitToPrintArea = 1
};
so the next flags can be 2, 4, 8, etc, meaning you can use binary or and binary
and on them and it'll all work
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D18179
To: michaelweghorn, #okular, ngraham, sander
Cc: aacid, fvogt, okular-devel, tfella, ngraham, darcyshen
D10974: Add option to ignore print margins for non-PDF generators
aacid added inline comments. INLINE COMMENTS > michaelweghorn wrote in document.h:728 > I have changed the return type to a QWidget* again, but only for the Document > class itself, not in the other places. As far as I understand, this place > here is the only one relevant for the ABI. Is this correct? > > Currently, there is no complaint if a plain QWidget* is returned, it's just > handled as it used to be then. Should I change that (e.g. emit a > 'qWarning()')? interfaces/ is also installed when doing make install so compatibility there is also important. Since you have a dynamic cast in part.cpp i guess it makes sense to have a warning when the dynamic cast fails? Telling the "developer" that he should update her implementation of the method? REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D10974 To: michaelweghorn, #okular Cc: fvogt, rkflx, arthurpeters, ltoscano, okular-devel, aacid, ngraham, tfella, darcyshen
[okular] [Bug 402756] Highlight annotation should inherit visual style (e.g. rounded vs square) from widget theme
https://bugs.kde.org/show_bug.cgi?id=402756 avlas changed: What|Removed |Added Resolution|--- |UPSTREAM Status|REPORTED|RESOLVED --- Comment #8 from avlas --- > Only that this is not a selection, this is an highlight annotation, widget > styles don't have the concept of "highlight annotation", so no this has > nothing to do with "The visual style". > > On top of that what you're seeing is not rendered by Okular but by Poppler, > the ones rendered by Okular (i.e. non pdf file highlights) have square > corners. I see. Good to know. Thanks! > I'd sincerely close this bug as NOT A BUG I'd disagree. I think closing as UPSTREAM would be more appropriate then... (I may consider reporting it to Poppler, will see). I'm doing it myself. Change it if you feel it is not proper. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403178] Buggy Zoom Out
https://bugs.kde.org/show_bug.cgi?id=403178 Albert Astals Cid changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #3 from Albert Astals Cid --- Trim Margins is not an option enabled by default so i guess you enabled it. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 342003] Trim margins confuses ordering of zoom steps while zooming out
https://bugs.kde.org/show_bug.cgi?id=342003 Albert Astals Cid changed: What|Removed |Added CC||alt.su-7oon2...@yopmail.com --- Comment #9 from Albert Astals Cid --- *** Bug 403178 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403178] Buggy Zoom Out
https://bugs.kde.org/show_bug.cgi?id=403178 Albert Astals Cid changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #4 from Albert Astals Cid --- *** This bug has been marked as a duplicate of bug 342003 *** -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403004] Single page non scrolling
https://bugs.kde.org/show_bug.cgi?id=403004 Albert Astals Cid changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REPORTED --- Comment #3 from Albert Astals Cid --- Yeah Nate didn't read what you wrote carefully enough i think. Now honestly i don't think that what you're requesting makes much sense, but since Evince does it and you also want it, i guess there's at least two people in the world that think it makes sense :D -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402756] Highlight annotation should inherit visual style (e.g. rounded vs square) from widget theme
https://bugs.kde.org/show_bug.cgi?id=402756 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org --- Comment #7 from Albert Astals Cid --- (In reply to Nate Graham from comment #5) > Yeah, I think this is fine personally. But I do think it would be a sensible > change to inherit the selection style from the widget theme. That way themes > with square selection highlights (like Breeze) would give you what you want. Only that this is not a selection, this is an highlight annotation, widget styles don't have the concept of "highlight annotation", so no this has nothing to do with "The visual style". On top of that what you're seeing is not rendered by Okular but by Poppler, the ones rendered by Okular (i.e. non pdf file highlights) have square corners. I'd sincerely close this bug as NOT A BUG -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403247] Markdown backend: hyperlinks across multiple lines don't work
https://bugs.kde.org/show_bug.cgi?id=403247 Albert Astals Cid changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||aa...@kde.org Resolution|--- |WAITINGFORINFO --- Comment #1 from Albert Astals Cid --- Can you attach such a file? -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403004] Single page non scrolling
https://bugs.kde.org/show_bug.cgi?id=403004 --- Comment #2 from Kja --- (In reply to Nate Graham from comment #1) > Okular has the same settings: > > Check View > Page Width > Uncheck View > Continuous > > In this state, it will stop at the end of the page and only another scroll > tick will move to the next page. No, its not the same setting. If i use Check View > Page Width Uncheck View > Continuous In Evince, and if i scroll down the page. I stop at the bottom of the page how matter much i scroll. Only pressing a bottom (next) or arrow (next) will let me go to the next page. This is what i want. This is not the case in okular, here i scroll down to the next page like it was Continuous mode. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402756] Highlight annotation should inherit visual style (e.g. rounded vs square) from widget theme
https://bugs.kde.org/show_bug.cgi?id=402756 --- Comment #6 from avlas --- (In reply to Nate Graham from comment #5) > Yeah, I think this is fine personally. But I do think it would be a sensible > change to inherit the selection style from the widget theme. That way themes > with square selection highlights (like Breeze) would give you what you want. That would be great! -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403247] New: Markdown backend: hyperlinks across multiple lines don't work
https://bugs.kde.org/show_bug.cgi?id=403247 Bug ID: 403247 Summary: Markdown backend: hyperlinks across multiple lines don't work Product: okular Version: 1.6.1 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-devel@kde.org Reporter: destroyer2...@aim.com Target Milestone: --- SUMMARY With Okular's markdown backend, hyperlinks that are broken into multiple lines due to formatting appear as they should but are not clickable. STEPS TO REPRODUCE 1. Open a markdown file in Okular that has hyperlinks with long names. 2. Find a hyperlink that starts on one line and ends on another. 3. Hover over said hyperlink. OBSERVED RESULT Hyperlink will not be clickable. EXPECTED RESULT Hyperlink should be clickable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 4.20.1-arch1-1-ARCH KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.12.0 -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403004] Single page non scrolling
https://bugs.kde.org/show_bug.cgi?id=403004 Nate Graham changed: What|Removed |Added Resolution|--- |WORKSFORME CC||n...@kde.org Status|REPORTED|RESOLVED --- Comment #1 from Nate Graham --- Okular has the same settings: Check View > Page Width Uncheck View > Continuous In this state, it will stop at the end of the page and only another scroll tick will move to the next page. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402756] Highlight annotation should inherit visual style (e.g. rounded vs square) from widget theme
https://bugs.kde.org/show_bug.cgi?id=402756 Nate Graham changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- Summary|Highlight rounded style |Highlight annotation should |looks archaic |inherit visual style (e.g. ||rounded vs square) from ||widget theme --- Comment #5 from Nate Graham --- Yeah, I think this is fine personally. But I do think it would be a sensible change to inherit the selection style from the widget theme. That way themes with square selection highlights (like Breeze) would give you what you want. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402779] Okular, when printing 2 pages per sheet, prints the wrong pages.
https://bugs.kde.org/show_bug.cgi?id=402779 Nate Graham changed: What|Removed |Added CC||n...@kde.org --- Comment #1 from Nate Graham --- Albert/other Okular devs, was this a Qt issue? I forget. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402756] Highlight rounded style looks archaic
https://bugs.kde.org/show_bug.cgi?id=402756 --- Comment #4 from avlas --- (In reply to Nate Graham from comment #3) > > Anyway, would you consider having an option to modulate how rounded > > highlighting looks? Would that be hard to implement? > No, this isn't reasonable, sorry. This kind of thing should be determined by > the widget style, not specific to Okular. > > Can you attach a screenshot of what you're seeing? It doesn't really look > that round to me. Please see the link: https://user-images.githubusercontent.com/3875196/51194918-09dd6a00-18ba-11e9-9aaa-71b4bf232d88.png I very much prefer sharp highlights, but it's fine if you like rounded highlights. There's not much I can do anyways :) -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 403148] Cannot print in original size to paper printer
https://bugs.kde.org/show_bug.cgi?id=403148 Nate Graham changed: What|Removed |Added Resolution|--- |DUPLICATE CC||n...@kde.org Status|REPORTED|RESOLVED --- Comment #2 from Nate Graham --- *** This bug has been marked as a duplicate of bug 348172 *** -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 348172] Scaling options missing in print dialog
https://bugs.kde.org/show_bug.cgi?id=348172 Nate Graham changed: What|Removed |Added CC||h.lo...@gmx.de --- Comment #22 from Nate Graham --- *** Bug 403148 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402756] Highlight rounded style looks archaic
https://bugs.kde.org/show_bug.cgi?id=402756 Nate Graham changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||n...@kde.org Resolution|--- |WAITINGFORINFO --- Comment #3 from Nate Graham --- > Anyway, would you consider having an option to modulate how rounded > highlighting looks? Would that be hard to implement? No, this isn't reasonable, sorry. This kind of thing should be determined by the widget style, not specific to Okular. Can you attach a screenshot of what you're seeing? It doesn't really look that round to me. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402734] Option to open the file created with the "File > Export As..." operation
https://bugs.kde.org/show_bug.cgi?id=402734 Nate Graham changed: What|Removed |Added Summary|File > Export As... > |Option to open the file |Auto-open created file |created with the "File > ||Export As..." operation -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402734] File > Export As... > Auto-open created file
https://bugs.kde.org/show_bug.cgi?id=402734 Nate Graham changed: What|Removed |Added CC||n...@kde.org --- Comment #3 from Nate Graham --- I agree with Albert here. Auto-opening would be super-annoying. Here's another idea though: display a notification that the export operation was successful, and put an "Open" button in the notification. This is what Spectacle does and people seem to like it. If a notification is too intrusive, maybe we could use a KMessageWidget instead. -- You are receiving this mail because: You are the assignee for the bug.
D18179: PDF: Implement scaling for non-rasterized printing
michaelweghorn marked an inline comment as done. michaelweghorn added a comment. Thanks for the feedback and info. I've update the change accordingly now. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18179 To: michaelweghorn, #okular, ngraham, sander Cc: aacid, fvogt, okular-devel, tfella, ngraham, darcyshen
D18179: PDF: Implement scaling for non-rasterized printing
michaelweghorn marked 2 inline comments as done. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18179 To: michaelweghorn, #okular, ngraham, sander Cc: aacid, fvogt, okular-devel, tfella, ngraham, darcyshen
D18179: PDF: Implement scaling for non-rasterized printing
michaelweghorn updated this revision to Diff 49519. michaelweghorn added a comment. Undo accidental whitespace changes REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D18179?vs=49518=49519 BRANCH michaelweghorn/UPDATE_20191115_D18179_allowScaledPrintingWithoutRasterization REVISION DETAIL https://phabricator.kde.org/D18179 AFFECTED FILES core/fileprinter.cpp core/fileprinter.h generators/poppler/generator_pdf.cpp To: michaelweghorn, #okular, ngraham, sander Cc: aacid, fvogt, okular-devel, tfella, ngraham, darcyshen
D18179: PDF: Implement scaling for non-rasterized printing
michaelweghorn updated this revision to Diff 49518. michaelweghorn added a comment. Implement improvements suggested by Albert: - use an enum rather than a bool for scale mode - avoid ABI breakage by adding extra methods that take an additional parameter for scale mode and make existing methods call those What's a bit ugly here is that 'scaleMode' cannot be the last parameter in the new 'FilePrinter::printFile' method, as it has to come before those params that have a default value. REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D18179?vs=49225=49518 BRANCH michaelweghorn/UPDATE_20191115_D18179_allowScaledPrintingWithoutRasterization REVISION DETAIL https://phabricator.kde.org/D18179 AFFECTED FILES core/fileprinter.cpp core/fileprinter.h generators/poppler/generator_pdf.cpp To: michaelweghorn, #okular, ngraham, sander Cc: aacid, fvogt, okular-devel, tfella, ngraham, darcyshen
[okular] [Bug 403148] Cannot print in original size to paper printer
https://bugs.kde.org/show_bug.cgi?id=403148 Oliver Sander changed: What|Removed |Added CC||oliver.san...@tu-dresden.de --- Comment #1 from Oliver Sander --- Full-page printing is in the works. A bleeding-edge Okular will give you the desired option under 'PDF Options'. -- You are receiving this mail because: You are the assignee for the bug.
D10974: Add option to ignore print margins for non-PDF generators
michaelweghorn edited the summary of this revision. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D10974 To: michaelweghorn, #okular Cc: fvogt, rkflx, arthurpeters, ltoscano, okular-devel, aacid, ngraham, tfella, darcyshen
D10974: Add option to ignore print margins for non-PDF generators
michaelweghorn marked an inline comment as done. michaelweghorn added inline comments. INLINE COMMENTS > aacid wrote in document.h:728 > this is binary incompatible :/ > > We could just let it be a QWidget but document it has to be a > PrintOptionsWidge subclass, and then on the user do a dynamic_cast and > complain if it is not a PrintOptionsWidget, but maybe we can just say meh and > break the BC. I have changed the return type to a QWidget* again, but only for the Document class itself, not in the other places. As far as I understand, this place here is the only one relevant for the ABI. Is this correct? Currently, there is no complaint if a plain QWidget* is returned, it's just handled as it used to be then. Should I change that (e.g. emit a 'qWarning()')? REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D10974 To: michaelweghorn, #okular Cc: fvogt, rkflx, arthurpeters, ltoscano, okular-devel, aacid, ngraham, tfella, darcyshen
D10974: Add option to ignore print margins for non-PDF generators
michaelweghorn updated this revision to Diff 49510. michaelweghorn edited the summary of this revision. michaelweghorn added a comment. Adapt according to Albert's feedback: - undo ABI breakage by changing back signature of 'Document::printConfigurationWidget()' to what it is like without this change, and use a 'dynamic_cast' in 'Part::slotPrint'. - drop 'virtual' for 'PDFOptionsPage::ignorePrintMargins()' REPOSITORY R223 Okular CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D10974?vs=49223=49510 BRANCH michaelweghorn/WAITING_FOR_REVIEW_D10974_add_scaling_options_for_other_generators REVISION DETAIL https://phabricator.kde.org/D10974 AFFECTED FILES CMakeLists.txt core/document.cpp core/document.h core/fileprinter.cpp core/printoptionswidget.cpp core/printoptionswidget.h generators/poppler/generator_pdf.cpp generators/poppler/generator_pdf.h interfaces/printinterface.h part.cpp To: michaelweghorn, #okular Cc: fvogt, rkflx, arthurpeters, ltoscano, okular-devel, aacid, ngraham, tfella, darcyshen
