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.
Not be implemented in .UNO to be available to all toolbars, but possibly could be added to Find toolbar.
I would keep the toolbar simple. It's overcrowded right now and those advanced options are better placed at the dialog.
(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.
(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)?
(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).
(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.
(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?
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.
(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.
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.
(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..
*** Bug 134150 has been marked as a duplicate of this bug. ***