Comment 8 for bug 1171809

Revision history for this message
Ari (ari-lp) wrote :

Hi Adam,

the result highlighting works absolutely fine now. Thanks again for the quick fix. As for the change itself I think that it's a major improvement over the previous highlighting method. Still there are three points I would like to discuss that might enhance the current method even further:

1.) The highlighting color changes when window focus is lost. I don't know if this is intentional or not but I would argue that it makes the results harder to identify. One use case where this would be a problem is when working with qpdfview and a document editor side by side. This point also applies to other UI elements such as the search progress indicator and thumbnail highlighter.

2.) Depending on the zoom level characters are sometimes ever so slightly protruding over the highlighting box, which appears to be a bit off center in general. I know that this is nitpicking but I figured I should mention it in case it is easy to fix. If not, please just disregard this point. I attached a screenshot showcasing what I mean.

3.) This point pertains more to the future of qpdfview than its current state. From the bug overview I can see that you have triaged bug #958634 (enhancements for text selection) so I think it is safe to say that at some point in the future there will be text selection by line. This is why I wonder how result highlighting and text highlighting colors will be handled when this feature eventually comes. As it stands, qpdfview's new highlighting method uses the system highlighting color, which would conflict with a potential new text selection tool. I think this might be a good reason to rethink how the result highlighting color is defined.

4.) As a follow-up to point 3.) I would like to add that the current method of defining the result color based on the system highlighting color can make the results quite hard to read depending on the theme. This is to be expected when a background color that is usually rendered behind white text now serves to highlight black text. I think there are two ways of handling this:

  a.) Render highlighted text in XOR mode (white text on colored background), this might lead to problems with 3.)
  b.) Offer a configuration option to change the result highlighting color. Set the default color of the color selection option to a slightly modified version of the system highlighting color (e.g. increased brightness) to avert confusion around 3.)

All of these points are a bit pedantic, so please just set them aside for now if you have more important things to attend to.

#####

I just realized that I completely forgot to address your response on caching.

What you wrote was:

> Concerning caching, I don't think the results are lost on switching tabs any more. You can switch tabs, search for something else, switch back and continue to review the results of your last search using find next/previous. Its only the contents of the search field that will not match the displayed highlights.

You're right, I wasn't aware of that. I guess I always changed the search terms back before searching through the tab and thus triggered a new search. I think the point still stands, though. Searches in larger documents (think hundreds of pages) can be quite resource-intensive and should be avoided if possible (e.g. not reengaging a new search if the same term is used after closing the search bar). A persistent cache would help with that and I think it would fit well with qpdfview's lightweighted nature and its efficiency.

Thanks again for taking the time to read this.

Cheers
--Ari