Bug 106723 - Better visibility of not found search term
Summary: Better visibility of not found search term
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.1.2 release
Hardware: All All
: medium enhancement
Assignee: rptr
URL:
Whiteboard: target:6.3.0
Keywords: difficultyInteresting, easyHack, skillCpp, topicUI
Depends on:
Blocks: Find-Search
  Show dependency treegraph
 
Reported: 2017-03-23 14:08 UTC by Thomas Lendo
Modified: 2019-04-18 07:59 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Find toolbar with and without colored textbox background in Mozilla Firefox (2.30 KB, image/png)
2017-03-23 14:08 UTC, Thomas Lendo
Details
Cut search result information string (66.89 KB, image/png)
2017-03-26 17:02 UTC, Thomas Lendo
Details
Examples for better visiblity of not found search term (328.14 KB, application/vnd.oasis.opendocument.text)
2019-03-30 07:40 UTC, Jim Raykowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2017-03-23 14:08:15 UTC
Created attachment 132102 [details]
Find toolbar with and without colored textbox background in Mozilla Firefox

The current version of LibO displays "Search key not found" in the "Find & Replace" dialog window and in the right of the the "Find" toolbar.

A more visible (additional) way to show the user that the term isn't found in the document would be coloring the text box where the searched string is written in.

Mozila Firefox uses a red background color in the text box to show that nothing is found.

Benefit:
- In case of less space (e.g. in the sidebar or if the Find toolbar is placed in the right of the Standard toolbar) the coloring doesn't need any extra space to give the user the needed information.
- The user can't overlook the color information.
Comment 1 Heiko Tietze 2017-03-23 16:06:37 UTC
Color must not be the primary and only indicator of information. So a "not found" is still required, though it could be placed inline. I dislike the red highlighting as this color is reserved for errors and system relevant warnings. Not found could be an intentional result of a search.

On the other hand the text is not easy to see at the current position. So my suggestion is to have a dedicated section where the number of results are show. If you search for "Test" in a dummy text (dt+f3 for English) you get "0 results", "He" could results in "1+ results" for simple Find and "42 results" for Find all. Maybe combined with next/previous so that a numerical stepper allows to go to the 5th citation.

NEW for the better visibility, keeping NEEDSUX for further input.
Comment 2 Thomas Lendo 2017-03-26 17:02:07 UTC
Created attachment 132152 [details]
Cut search result information string

The string as search information is useful and I like the idea to put it into the search box (e.g. right aligned) itself. Maybe Firefox did that in the past? I can't remember.

Now the string sometimes is cut at the right (see attached screenshot) in case of less space in the toolbar. I wonder that wasn't recognized during implementation - the free positioning of toolbars is a key personalization feature of LibO and not everyone is using the Fing toolbar at the bottom of the Writer view in its standard position (other toolbars and other functionality are above or at the right in the sidebar but searching is below the content which causes unnecessary mouse movement for me).

Showing the number of results ist an excellent idea! But in my opinion that would be another bug. This bug is intended for better visualization if there is a search result or not.
Comment 3 Cor Nouws 2017-08-18 17:30:12 UTC
could be an easyhack ?
Comment 4 Heiko Tietze 2018-07-07 07:51:35 UTC Comment hidden (no-value)
Comment 5 Jim Raykowski 2018-07-08 02:00:19 UTC
If anyone interested in working on this I can give code pointers from experience with tdf#81925 and tdf#116596
Comment 6 Jim Raykowski 2018-07-08 02:09:20 UTC
Looks like I should have used bug 81925 and bug 116596 for the linking to work and add bug 115600
Comment 7 Xisco Faulí 2018-07-08 11:40:38 UTC
(In reply to Jim Raykowski from comment #5)
> If anyone interested in working on this I can give code pointers from
> experience with tdf#81925 and tdf#116596

You can also add the code pointers and add the keyword easyHack :)
Comment 8 Jim Raykowski 2018-07-08 17:00:50 UTC
Would it be ok if I just take this one?
Comment 9 Jim Raykowski 2018-07-10 15:56:31 UTC
First let's see if anyone starting out hacking LO is interested in this.

- Code Pointer -
 
Set the search label control background in these locations:

srchdlg.hxx:SvxSearchDialog::SetSearchLabel
srchdlg.cxx:lcl_SetSearchLabelWindow
tbunosearchcontrollers.cxx:SearchLabelToolboxController::statusChanged
Comment 10 Jim Raykowski 2019-03-30 07:40:42 UTC
Created attachment 150409 [details]
Examples for better visiblity of not found search term

Attached are some visual ideas to make the not found search messages more visible.
Comment 11 Heiko Tietze 2019-04-01 07:56:29 UTC
(In reply to Jim Raykowski from comment #10)
> Created attachment 150409 [details]
> Examples for better visiblity of not found search term
> 
> Attached are some visual ideas to make the not found search messages more
> visible.

The red font color in the search input looks very salient to me. "Not found text color" is actual the search term but in red. However, I wonder what happens when the dropdown expands or when users enter text. It should go back to the default if it differs to the not found item. The right-hand message could be done in black but the red is not disturbing. 

Wouldn't add an option for the search message, way too much customization and green for not found makes no sense. Also the (yellow) background color is typically used for selections not warnings.
Comment 12 rptr 2019-04-02 15:41:39 UTC
(In reply to Jim Raykowski from comment #10)
> Created attachment 150409 [details]
> Examples for better visiblity of not found search term
> 
> Attached are some visual ideas to make the not found search messages more
> visible.

I didn't see this until now. I've just now worked out this feature (i was delayed by some refactoring (weld) done to the code). I went for the background highlighting approach but changing to a foreground highlight would be trivial.

I did not realise that you meant for the SearchLabel to be highlighted (it was somewhat unclear), but that should be an easy fix at this stage.
Comment 13 rptr 2019-04-02 15:42:41 UTC
(In reply to rptr from comment #12)
> (In reply to Jim Raykowski from comment #10)
> > Created attachment 150409 [details]
> > Examples for better visiblity of not found search term
> > 
> > Attached are some visual ideas to make the not found search messages more
> > visible.
> 
> I didn't see this until now. I've just now worked out this feature (i was
> delayed by some refactoring (weld) done to the code). I went for the
> background highlighting approach but changing to a foreground highlight
> would be trivial.
> 
> I did not realise that you meant for the SearchLabel to be highlighted (it
> was somewhat unclear), but that should be an easy fix at this stage.

Basically I was trying to get a full red background for the text input field like in the Firefox screenshot attachment.
Comment 14 Jim Raykowski 2019-04-02 19:31:04 UTC
(In reply to rptr from comment #13)
> Basically I was trying to get a full red background for the text input field
> like in the Firefox screenshot attachment.

Were you able to get the full combobox subedit background to fill? I could not.

Another thing I have been looking at is changing the text color to red if the search term is not found while the search term is being entered.
Comment 15 rptr 2019-04-03 00:26:29 UTC
(In reply to Jim Raykowski from comment #14)
> 
> Were you able to get the full combobox subedit background to fill? I could
> not.
> 
> Another thing I have been looking at is changing the text color to red if
> the search term is not found while the search term is being entered.

No. I asked about this on IRC, it is some platform thing apparently. SetControlBackground would give you a fully red background on Windows, while on Ubuntu (in the example) only the text background ("selection") changed color, took me ages to figure that out.
Comment 16 rptr 2019-04-03 00:30:32 UTC
(In reply to Jim Raykowski from comment #14)
> 
> Were you able to get the full combobox subedit background to fill? I could
> not.
> 

No. I asked about this on IRC, it is some platform thing apparently. SetControlBackground would give you a fully red background on Windows, while on Ubuntu (in the example) only the text background ("selection") changed color, took me ages to figure that out.

> Another thing I have been looking at is changing the text color to red if
> the search term is not found while the search term is being entered.

This should maybe be a different bug? I'd be willing to do it since I'm already deep in this code now.

Now that SvxSearchDialog uses the "weld" thing I am not sure how to do the background in GTK (VCL is done), so caolan on IRC advised to use "set_entry_error".
Comment 17 Jim Raykowski 2019-04-03 04:54:46 UTC
(In reply to rptr from comment #15)
> (In reply to Jim Raykowski from comment #14)
> > 
> > Were you able to get the full combobox subedit background to fill? I could
> > not.
> > 
> > Another thing I have been looking at is changing the text color to red if
> > the search term is not found while the search term is being entered.
> 
> No. I asked about this on IRC, it is some platform thing apparently.
> SetControlBackground would give you a fully red background on Windows, while
> on Ubuntu (in the example) only the text background ("selection") changed
> color, took me ages to figure that out.

I was thinking it had to do with the vcl backend used. I don't have a Window build so didn't know that it works there.
Comment 18 rptr 2019-04-03 08:09:19 UTC
(In reply to Jim Raykowski from comment #17)
> I was thinking it had to do with the vcl backend used. I don't have a Window
> build so didn't know that it works there.

Hey, would be great if you could check out the result. To be honest I'm not too pleased, doesn't look coherent enough, but the task turned out to go beyond the code pointers (SetControlBackground in 3 methods).
Comment 19 Xisco Faulí 2019-04-03 09:03:00 UTC
(In reply to Jim Raykowski from comment #17)
> (In reply to rptr from comment #15)
> > (In reply to Jim Raykowski from comment #14)
> > > 
> > > Were you able to get the full combobox subedit background to fill? I could
> > > not.
> > > 
> > > Another thing I have been looking at is changing the text color to red if
> > > the search term is not found while the search term is being entered.
> > 
> > No. I asked about this on IRC, it is some platform thing apparently.
> > SetControlBackground would give you a fully red background on Windows, while
> > on Ubuntu (in the example) only the text background ("selection") changed
> > color, took me ages to figure that out.
> 
> I was thinking it had to do with the vcl backend used. I don't have a Window
> build so didn't know that it works there.

Does it not work if you use SAL_USE_VCLPLUGIN=gen ?
Comment 20 Jim Raykowski 2019-04-04 01:12:55 UTC
(In reply to Xisco Faulí from comment #19)
> 
> Does it not work if you use SAL_USE_VCLPLUGIN=gen ?

Yes SetControlBackground works when I use SAL_USE_VCLPLUGIN=gen. I didn't know about that VCLPLUGIN. It shows as VCL: x11 in the Help dialog.
Thanks Xisco!
Comment 21 Jim Raykowski 2019-04-04 01:37:36 UTC
(In reply to rptr from comment #18)

> Hey, would be great if you could check out the result. To be honest I'm not
> too pleased, doesn't look coherent enough, but the task turned out to go
> beyond the code pointers (SetControlBackground in 3 methods).

Looks like the weld controls don't allow setting colors like vcl controls. For Gtk3 weld::ComboBox::set_entry_error displays ! in the edit box and for Gtk2 and X11 the text is changed to red. I couldn't find a way to change the text color of the weld::Label m_xSearchLabel.

Looking forward to seeing your patch.
Comment 22 rptr 2019-04-04 02:31:41 UTC
(In reply to Jim Raykowski from comment #21)
> Looks like the weld controls don't allow setting colors like vcl controls.
> For Gtk3 weld::ComboBox::set_entry_error displays ! in the edit box and for
> Gtk2 and X11 the text is changed to red. I couldn't find a way to change the
> text color of the weld::Label m_xSearchLabel.
> 
> Looking forward to seeing your patch.

It's here https://gerrit.libreoffice.org/#/c/70173/
Comment 23 rptr 2019-04-09 22:33:36 UTC
Since you (Heiko and Jim) both seem to like the red foreground, I settled for it. The partially red background just doesn't look very good.
Comment 24 Jim Raykowski 2019-04-10 03:14:15 UTC
(In reply to rptr from comment #23)
> Since you (Heiko and Jim) both seem to like the red foreground, I settled
> for it. The partially red background just doesn't look very good.

TBH I didn't see Thomas's initial attachment until after you started working on this. The code pointers were given with the idea that the not found search message was what was wanted to have better visibility. It seems now that the Find & Replace dialog is welded it leaves us with only the ability to use set_entry_error to achieve better visibility of the not found search term. This shows as light red text for gen and gtk2 backends and a '!' to the far right of the edit box for gtk3 backend. Using light red text for better visibility of search term not found in the find tool bar find text box would at least be consistent with the gen and gtk2 backends. It might be best to leave the not found search message alone in the find tool bar to be consistent with the Find & Replace dialog search message since it doesn't seem weld::label text foreground or background color can be changed.
Comment 25 rptr 2019-04-12 12:08:46 UTC
(In reply to Jim Raykowski from comment #24)
> TBH I didn't see Thomas's initial attachment until after you started working
> on this. The code pointers were given with the idea that the not found
> search message was what was wanted to have better visibility. It seems now
> that the Find & Replace dialog is welded it leaves us with only the ability
> to use set_entry_error to achieve better visibility of the not found search
> term. This shows as light red text for gen and gtk2 backends and a '!' to
> the far right of the edit box for gtk3 backend. Using light red text for
> better visibility of search term not found in the find tool bar find text
> box would at least be consistent with the gen and gtk2 backends. It might be
> best to leave the not found search message alone in the find tool bar to be
> consistent with the Find & Replace dialog search message since it doesn't
> seem weld::label text foreground or background color can be changed.

Alright, I followed your advice. Noticed that my patch had some junk in it, but I'm fairly confident that the latest patch is as good as it's going to get, would be great if you could review and merge :)

https://gerrit.libreoffice.org/#/c/70662/

Not sure why gerrit creates new changes, IIRC it didn't do this before when I made a change and resubmitted...
Comment 26 Commit Notification 2019-04-18 01:12:45 UTC
Rasmus Jonsson committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/96bf1e53fba51ad42742bba66469bea911b57325%5E%21

tdf#106723 Improve visibility of not found search term

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.