Bug 129469 - UI: Add customize option to find "Whole words only" to Find toolbar, as available from Find & Replace dialog
Summary: UI: Add customize option to find "Whole words only" to Find toolbar, as avail...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
: 134150 (view as bug list)
Depends on:
Blocks: Find-Toolbar
  Show dependency treegraph
 
Reported: 2019-12-18 12:43 UTC by sdc.blanco
Modified: 2020-06-22 04:51 UTC (History)
7 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2019-12-18 12:43:11 UTC
As best I can tell, it is not possible to add "Whole Words only" option to a toolbar (e.g., Find Toolbar).  (i.e., it is not available in Tools > Customize, Toolbars, Available Commands).  It is necessary to open the Find & Replace window to select "Whole Words only". 

Because the Find toolbar can be docked at the bottom of the document window, it would be practical to have the possibility to Customize this option.
Comment 1 V Stuart Foote 2019-12-20 15:02:00 UTC
Not be implemented in .UNO to be available to all toolbars, but possibly could be added to Find toolbar.
Comment 2 Heiko Tietze 2019-12-23 08:46:30 UTC
I would keep the toolbar simple. It's overcrowded right now and those advanced options are better placed at the dialog.
Comment 3 sdc.blanco 2019-12-23 09:43:03 UTC
(In reply to Heiko Tietze from comment #2)
> I would keep the toolbar simple. 

Clarification:  Was not proposing to add this to the Find toolbar as standard.

Was proposing that there was a possibility for user customization.

(use case:  Find can be docked at the bottom of a document window.  Whole word is practical when searching for "present" (but not wanting "representation", "presentation", etc.)

I understand from comment #4 that it cannot be a .uno, but I can see that users can already turn off and on different features in the Find toolbar, as well as moving their position (i.e., with customization, one can control how crowded, and layout --  I have also added a Navigator to Find - so I do not experience it as crowded).  

Again:  only proposing possibility for user customization, not proposing that "whole word" should be shown as standard.
Comment 4 sdc.blanco 2019-12-23 09:54:07 UTC
(In reply to V Stuart Foote from comment #1)
> Not be implemented in .UNO to be available to all toolbars, but possibly
> could be added to Find toolbar.

No objection, but new question.

As an experiment, tried to remove "Match case" from Find toolbar (not by unclicking, but by using the using the  black "Remove item" arrow). 

As you already know (and I just learned), "Match case" does not show up in the "Function" list (where it can be added back).   (of course "reset" brings it back, but it also means that any customization is lost).

From a (naive) user perspective, there is no obvious difference between those icons (functions) that can be added back and those that cannot be added back to the Find toolbar.

Wouldn't it be appropriate to only allow "remove" item for those items in the Find toolbar that actually have .unos?  (and deactivate that function for non-.uno items that are specific to Find toolbar)?

I have not tested with other toolbars.  Do they also behave this way? Should this be filed as a separate bug report? (either for "Find" or for "toolbars" in general)?
Comment 5 V Stuart Foote 2019-12-23 14:28:59 UTC
(In reply to sdc.blanco from comment #4)
>...
> Wouldn't it be appropriate to only allow "remove" item for those items in
> the Find toolbar that actually have .unos?  (and deactivate that function
> for non-.uno items that are specific to Find toolbar)?
> 
> I have not tested with other toolbars.  Do they also behave this way? Should
> this be filed as a separate bug report? (either for "Find" or for "toolbars"
> in general)?

IMHO no issue. Pretty common and just manifestation of what is manipulated via GTK button action requiring UNO command, and what is hard-coded feature of specific dialog or toolbar (and restored by 'Reset').

Practice is to implement the UNO command when the command is useful in multiple GUI contexts--e.g. Toolbars, menus, and controls of Sidebar Deck and now Notebook Bar (ref bug 86899).
Comment 6 sdc.blanco 2019-12-26 18:34:23 UTC
(In reply to V Stuart Foote from comment #5)
> (In reply to sdc.blanco from comment #4)
> IMHO no issue. Pretty common and just manifestation of what is manipulated
> via GTK button action requiring UNO command, and what is hard-coded feature
> of specific dialog or toolbar (and restored by 'Reset').
Just to be sure that we are speaking about the same issue.   

I believe your sensible explanation concerns the principle of what gets coded as UNO or not.  No dispute there.

My focus here is on UI/UX.  From a (naive) user point of view, there are Add and Remove Item arrows for the Customize Find Toolbar dialog, so one would expect that if an item is removed, then it should be possible to add it back with the Add Item arrow.  I understand (from your explanations) why this naive expectation is false.

My main point is only that it seems problematic (and unnecessary) that users can remove icons from toolbars that can only be recovered by "resetting" the toolbar.  It is already possible for users to hide these items, by unchecking them in the Customize Toolbar.  

My query/proposal was to prevent the user to remove those non-UNO items from the Find toolbar.
Comment 7 V Stuart Foote 2019-12-26 19:29:27 UTC
(In reply to sdc.blanco from comment #6)

> My main point is only that it seems problematic (and unnecessary) that users
> can remove icons from toolbars that can only be recovered by "resetting" the
> toolbar.  It is already possible for users to hide these items, by
> unchecking them in the Customize Toolbar.  
> 
> My query/proposal was to prevent the user to remove those non-UNO items from
> the Find toolbar.

@Maxim, *

Any thoughts? Should the 'feature' in customization to remove items without UNO basis (and so no ability to restore) be limited?
Comment 8 Cor Nouws 2020-01-16 21:48:46 UTC
The more I think/read about it, the more I get convinced that we should simply stop discussing more options for the quick Find toolbar.
That should only do a quick find, without additional thinking required. So adding more choices, obfuscates the meaning, breaks the use.

Unless there is a very strong reason.
E.g. behavior that is really unexpected with a risk of false results.

This request, for me, is a won't change/fix.
Comment 9 sdc.blanco 2020-01-16 23:58:39 UTC
(In reply to Cor Nouws from comment #8)
> Unless there is a very strong reason.
1. Original request comes from a naive user, who sees the possibility in Tools▸Customize to customize the Find Toolbar -- sees checkbox options for "Find All" and "Match Case" and wonders why "Words only" is not on the list.  (was there a conscious decision to omit this option?)

2. Was never a proposal to make this universal or default, just a customization option.

3. If you are seeking use case: Find toolbar can be docked on the bottom of a window. Whole word is practical in a big manuscript, when searching for words that often appear in other words (e.g., "sent" or "present" (but not "representation", "presentation", etc.) Or searching on names and wanting "Maxwell" but not "Maxwell's".  At present, it is necessary and disruptive) to have to open a new dialog box to do this.
Comment 10 Heiko Tietze 2020-01-17 08:25:33 UTC
We discussed the topic in the design meeting. The workflow is to quickly find one or more places without considering special cases. That's up for the search dialog and the quick find toolbar should remain simple. The verdict is WF, see also bug 72080. Same decision has been made for bug 125282, for example.
Comment 11 Cor Nouws 2020-01-17 08:34:03 UTC
(In reply to sdc.blanco from comment #9)
> (In reply to Cor Nouws from comment #8)
> > Unless there is a very strong reason.
> 1. Original request comes from a naive user, who sees the possibility in
> Tools▸Customize to customize the Find Toolbar -- sees checkbox options for
> "Find All" and "Match Case" and wonders why "Words only" is not on the list.
> (was there a conscious decision to omit this option?)
I'm afraid not.
I remember issues with the length in some situations though.

> 2. Was never a proposal to make this universal or default, just a
> customization option.
That is true. But my point is: where does this request for more options end? ANd how will they behave. Do people want to remember the settings? Some do, some don't.. A never ending discussion, I'm afraid.

However I do think that bug 102506 is harder to decide on.

> 3. If you are seeking use case: Find toolbar can be docked on the bottom of
> a window. Whole word is practical in a big manuscript, when searching for
> words that often appear in other words (e.g., "sent" or "present" (but not
> "representation", "presentation", etc.) Or searching on names and wanting
> "Maxwell" but not "Maxwell's".  At present, it is necessary and disruptive)
> to have to open a new dialog box to do this.
Ctrl+H, <foo>, Enter, Enter, Esc  isn't that disruptive..
Comment 12 Heiko Tietze 2020-06-22 04:51:52 UTC
*** Bug 134150 has been marked as a duplicate of this bug. ***