Summary: | Found text (ctrl-f) highlight color should use System Settings "selection background" color, not be hard-coded yellow | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Frank Myhr <fmyhr> |
Component: | general | Assignee: | Okular developers <okular-devel> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | aacid, acrylint, fmyhr, luca76, nate, oliver.sander, paul, sarentasciyan, whyeven3223 |
Priority: | NOR | ||
Version: | 1.3.2 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | All | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=416703 https://bugs.kde.org/show_bug.cgi?id=429796 |
||
Latest Commit: | Version Fixed In: |
Description
Frank Myhr
2017-09-01 17:38:33 UTC
No, that solution doesn't work, because people that use dark themes (where selection is usually a white-ish color) would not see the selection when reading PDFs (that usually have a white background). @Albert Astals Cid: You're right, I didn't think of that as I don't personally use dark themes. Hmm... how about using system Selection Background color for the found text highlight, and its inverse color to draw a box around this highlight. And an option to invert these colors in case that works better with the theme in use? Perhaps someone who uses dark themes can chime in... Thanks, Frank Let's get the border around and then we can discuss if adding options to tweak it makes sense True, I was going to send a patch for that. Adding the border is now simply diff --git a/ui/pagepainter.cpp b/ui/pagepainter.cpp index 047220f95..94429af93 100644 --- a/ui/pagepainter.cpp +++ b/ui/pagepainter.cpp @@ -385,6 +385,8 @@ void PagePainter::paintCroppedPageOnPainter( QPainter * destPainter, const Okula QPainter painter(&backImage); painter.setCompositionMode(QPainter::CompositionMode_Multiply); painter.fillRect(highlightRect, highlightColor); + painter.setPen(Qt::black); + painter.drawRect(highlightRect); } } // 4B.4. paint annotations [COMPOSITED ONES] I am not convinced that hard-wiring Qt::black is a good idea. What is a good color? @Oliver Sander: Cool patch! I agree, color selection is now seeming more complicated than it first appeared. I began wondering about a dotted- or dashed-line border with, say, alternating dark and light pixels. But that seems unnecessarily complex to implement. What about using *2* rectangles, one just slightly bigger than the other, one in a dark and the other in a light color? Or even *4* rectangles in alternating dark and light colors? It seems THAT would be pretty easy to see as (at minimum) a double-box no matter what the theme and document colors in use... (In reply to Oliver Sander from comment #4) > True, I was going to send a patch for that. Adding the border is now simply > > diff --git a/ui/pagepainter.cpp b/ui/pagepainter.cpp > index 047220f95..94429af93 100644 > --- a/ui/pagepainter.cpp > +++ b/ui/pagepainter.cpp > @@ -385,6 +385,8 @@ void PagePainter::paintCroppedPageOnPainter( QPainter * > destPainter, const Okula > QPainter painter(&backImage); > > painter.setCompositionMode(QPainter::CompositionMode_Multiply); > painter.fillRect(highlightRect, highlightColor); > + painter.setPen(Qt::black); > + painter.drawRect(highlightRect); > } > } > // 4B.4. paint annotations [COMPOSITED ONES] > > I am not convinced that hard-wiring Qt::black is a good idea. What is a > good color? Maybe try KColorUtils::darken ? https://api.kde.org/frameworks/kguiaddons/html/namespaceKColorUtils.html#a11e97bbb394b7e619163c2cc6b9a513a No need for KColorUtils, QColor has 'darken' natively. Feel free to play with the parameter. Patch is at https://git.reviewboard.kde.org/r/130238/ Reviewboard is going away soon. Can you upload your to our Phabricator instance? https://phabricator.kde.org Thanks! I've slightly edited the summary to include "BUG: 384267" which will automatically close this bug report once the patch is committed. I don't think that's going to work, i'm 92.46% sure that BUG: needs to be at the beginning of the line at alone, not in a sentence like you wrote it. Ah, thanks Albert. Changed. I just want to echo this report as it affects my usage too. In order to improve my ability to sleep, I use redshift to reduce the colour temperature of my screen and tinted glasses to filter out blue light. The yellow highlight colour will easily get lost once I've gone below a certain temperature threshold and so, the ability to change the highlight colour for the search and find function would be greatly beneficial to users like myself. (In reply to Albert Astals Cid from comment #1) > No, that solution doesn't work, because people that use dark themes (where > selection is usually a white-ish color) would not see the selection when > reading PDFs (that usually have a white background). (In reply to Frank Myhr from comment #2) > Perhaps someone who uses dark themes can chime in... I use dark themes. All themes available in System Settings use blue or light blue for Selection Background, but I always change it to brown or purple, so it does not glare and the white text is still easily readable. (In many places, the Selection Background is used permanently, so it has potential to glare.) No my problem with Okular is different to yours. Text selection (using Text Selection mode) makes text invisible, because PDFs use black text. I need to change the Selection Background color locally in Okular, while I am relatively ok with yellow for Ctrl+F searching. Does this need another bug report? Although there is no color sheme entry for Search Highlight Background, I suggest adding these options: Configure -> General -> Appearance: [_] Use custom background color [KColorButton] (already there) [x] Use custom text selection color [KColorButton] [_] Use custom search highlight color [KColorButton] I already suggested to add another KColorButton to the Ctrl+F search bar, right? (In reply to David Hurka from comment #14) > No my problem with Okular is different to yours. Text selection (using Text > Selection mode) makes text invisible, because PDFs use black text. I need to > change the Selection Background color locally in Okular, while I am > relatively ok with yellow for Ctrl+F searching. Does this need another bug > report? Since this is about "search color" and your issues not with "search color", yes i would suggest you open a new bug. I am also affected by this problem. Yellow is a very effective highlight color, which makes search results unnoticeable. I would like to suggest that application contains 2 settings: 1: whether to use system default 2: if not then which color (color chooser). This should be relatively simple to implement. I also have issues with this. I run with KDE Night Mode enabled (i.e., the screen is significantly shifted towards yellow/orange). This causes yellow highlights to become essentially invisible (or very hard to to see) on the page. Also I regularly search PDFs with lots of small text and it can be hard (even without Night Mode on) to easily find bright-yellow on the page. More contrast to improve visibility is needed with Ctrl-F highlighting. ASIDE: Yellow is a great highlight colour when NOT using Night Mode, colour inversion, large text, and/or reviewing using yellow --otherwise it is the worst (as implemented in okular since Night Mode renders it essentially invisible, inversion makes it unseen-black and viewing using yellow essentially makes it unseen if the two overlap). Choosing any of the Accessibility settings does not work since none of these changes the highlight to something noticeable/contrasting. In most situations those settings the Ctrl-F hard-coded yellow background becomes invisible (i.e., essentially black if inverting colours) and although the letters highlighted are a slightly brighter/bolder yellow but such is not easy to see with Night Mode off (and essentially impossible to see with it on). I would like to ask that the Ctrl-F highlight be configurable as follows: * Status quo: Default to what currently happens. * Allow the user under Accessibility to choose a some sort of "High contrast invert" for Ctrl-F matches. The high contrast invert would completely invert what is underneath the Ctrl-F highlight box. Sure if the area underneath is 50% gray the inversion would be ~50% gray, i.e., useless, but Ctrl-F matches text and virtually all PDF pages have significant contrast between text and what is underneath the text so that a colour inversion should be very visible. Most documents though, the inversion would make Ctrl-F finds white letter with a black background. It would also be ideal to make user-customizable the colour of the border of the box that surrounds the Ctrl-F yellow highlight. The current colour "black" is useless: it blends in to the page's text (i.e., it doesn't draw the user's attention to the found text) and if Accessibility's invert colour (etc.) is chosen it becomes invisible, etc. Currently there are times when the only way I can see where a match is on a page is to turn off Night Mode completely --and even then I have to look carefully because most PDFs I look at have a lot of small text in them --the yellow is too subtle a colour for such to stand out easily. I missed mentioning I am using Okular v21.08.1 --but all past versions also have these issues. Please fix this bug. This is an accessibility issue to me (I cannot see much difference from white and yellow for my eye problem) |