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.
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.
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.
could be an easyhack ?
No more input from UX, so please implement.
If anyone interested in working on this I can give code pointers from experience with tdf#81925 and tdf#116596
Looks like I should have used bug 81925 and bug 116596 for the linking to work and add bug 115600
(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 :)
Would it be ok if I just take this one?
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
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.
(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.
(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.
(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.
(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.
(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.
(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".
(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.
(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).
(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 ?
(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!
(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.
(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/
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.
(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.
(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...
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.