Summary: | Search dialog doesn't support "whole word only" option | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Eyal Rozenberg <eyalroz1> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | enhancement | CC: | buzea.bogdan, erack, heiko.tietze, thomas.lendo, vsfoote |
Priority: | medium | ||
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 102847 | ||
Attachments: | potential UI mockup |
Description
Eyal Rozenberg
2019-08-26 22:25:04 UTC
Hmm, we already use ICU libs for regex and word bounds are already integral. Imagine it would not be too much of a stretch to use ICU word bounds in a search option. @Eike? If you search for H1 you find H10 but "H1" retrieves only this term. It's a very common and sufficient way for this restriction, isn't it? (In reply to Heiko Tietze from comment #2) > If you search for H1 you find H10 but "H1" retrieves only this term. If you search for "H1" (with the quotes) it looks for "H1" (with the quotes). I'm not sure what you mean by your comment. (In reply to V Stuart Foote from comment #1) I wonder if the relevant code in Writer won't just work essentially as-is. why not? (In reply to Eyal Rozenberg from comment #3) > If you search for "H1" (with the quotes) it looks for "H1" (with the > quotes). Correct, I was wrong. In principle I support a 'whole string only' search option to not have to use regex. We discussed this topic in the design meeting. While too many options are contraindicated to usability, these checkboxes are collapsed by default. So let's do and introduce a whole word option. Created attachment 153730 [details]
potential UI mockup
I was actually thinking about something like this as the UI, i.e. not in the collapsed section. Perhaps not in that position among the other boxes, but one of them. Sort of like we have in Writer.
Still, if you disagree - collapsed is better than nothing at all.
(In reply to Eyal Rozenberg from comment #8) I support your idea but you must have localizations in mind which need mostly more space than the English strings and we should avoid a second line. (In reply to Thomas Lendo from comment #9) > (In reply to Eyal Rozenberg from comment #8) > I support your idea but you must have localizations in mind which need > mostly more space than the English strings and we should avoid a second line. ... and isn't that already a problem with the existing checkboxes? (In reply to Eyal Rozenberg from comment #10) > ... and isn't that already a problem with the existing checkboxes? Yes. Now the dialog is for example much wider in German than in English what looks not good. When implementing this feature, an algorithm should be introduced that breaks the checkboxes into a second line in a logical and visually good way. (In reply to Thomas Lendo from comment #11) > When implementing this feature, an algorithm should be > introduced that breaks the checkboxes into a second line in a logical and > visually good way. Is there a separate bug page for that? (In reply to Eyal Rozenberg from comment #12) > (In reply to Thomas Lendo from comment #11) > > When implementing this feature, an algorithm should be > > introduced that breaks the checkboxes into a second line in a logical and > > visually good way. > Is there a separate bug page for that? Haven't found any yet. https://bugs.documentfoundation.org/showdependencytree.cgi?id=113136&hide_resolved=0 (In reply to Thomas Lendo from comment #11) > ...an algorithm should be > introduced that breaks the checkboxes into a second line in a logical and > visually good way. Objection. Multi-line check-/radio buttons are common on macOS but violate HIG on Windows and (all/most/some?) Linux WMs. The only solution is to make functions simple and easy to understand with a few words. (In reply to Heiko Tietze from comment #14) > Objection. Multi-line check-/radio buttons are common on macOS but violate > HIG on Windows and (all/most/some?) Linux WMs. The only solution is to make > functions simple and easy to understand with a few words. I think you're misunderstanding Thomas: He meant (IIANM) conditionally having more than one line of checkboxes, not having individual checkboxes with more than one line of text. Regardless - I feel implementing this feature is more important than its exact placement. So I wouldn't mind if it were added to the "Other options" set of boxes at first, after which point the argument about where it should be placed could continue (or not continue...) (In reply to Eyal Rozenberg from comment #15) > Regardless - I feel implementing this feature is more important than its > exact placement. So I wouldn't mind if it were added to the "Other options" > set of boxes at first, after which point the argument about where it should > be placed could continue (or not continue...) I support that it should be placed in the other options area. The 'whole cell' setting in Calc is the pendant to Writer's 'whole word' setting and not the mentioned 'whole string only' search option of this bug report. If the 'whole string only' search option should be placed in the checkboxes area under the search field, this decision should be well justified as space is rare. Not here yet... Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: f2389a70da606768a39ee599de6a5b24058734aa CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded The discussion blocked from the placement of the option. (In reply to BogdanB from comment #17) > The discussion blocked from the placement of the option. Note that that's not a blocker. This feature can be implemented in two steps: first, the functionality (a flag that is passed to the implementation that does the actual search, and the search that honors that flag itself); then the UI part can be implemented, with the control defining that flag in the dialog decided. Additionally, the first step would already enable using it in macros. |