Created attachment 193515 [details] Screenshot Follow-up to bug 95405: Some results are two lines long, some three. And all result nodes are equally sized, which looks odd. Besides the variable height, a reasonable margin on top/bottom as well as left/right should be done. It might also be more appealing if the nodes receive a panel look-and-feel with a background color and rounded corners. https://extensions.libreoffice.org/en/extensions/show/132
I confirm it with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7c2ed9919d6d9d286d9062b91577d6bb2b7de8aa CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded But I would treat this as anhancement and not as a bug.
*** Bug 160999 has been marked as a duplicate of this bug. ***
I'm actually against variable space for results, at least by default. I would rather have equal size - but small equal size, without gratuitous spacing. See my comments on bug 160999 and sorry for the "status change spam".
Related concerns were brought up in bug 160999, which should be taken into account when fixing the Find Sidebar's inadequate use of space. My summary of Eyal's comments: - too much whitespace between matches currently - results could all be single-line - uniform and variable height have pros and cons (you said "width" in bug 160999 comment 11 but I assume you meant "height") - if multi-line allowed, number of lines of context could be controlled by a setting - if need to truncate, always show beginning of search string and truncate the rest to the width of sidebar Eyal, feel free to correct the above. Regarding a potential "context setting", see also attachment 189564 [details] showing how Voyant Tools' "Contexts" widget offers control over how much is shown, in both single-line view and in "expanded" view. I created that attachment for the enhancement request to the Search Results dialog in bug 157227.
(In reply to Stéphane Guillou (stragu) from comment #5) So, there are two conflicting user "desires" or interests which are expressed in this bug and in the dupe bug: * The desire for search result listings to take up vertical space to **vertically fit their contents** (rather then made uniform with empty space) * The desire to examine many results in a cursory manner, which is catered to by assigning them **short, uniform, heights**. It doesn't seem any of these desires can be just discounted/discarded in favor of the other ones - meaning that some configurability is in order in how this is resolved. Heiko, as you devise approach(es) for handling this, I would appreciate it if you could give a rough plan of what you intend to implement, for us to provide some more feedback. A few other points from the dupe bug or inspired by it: 1. Let's not be afraid of truncation. There's always the possibility of putting more text in a tooltip; and the user can always click a truncated result to bring it up in the main part of the window, for the full context. 2. The context for a search term match isn't very well-defined. One can always go wider, with surrounding lines or paragraphs, or narrower, taking just a sentence rather than a paragraph, or a clause in a sentence etc. 3. Search terms are: (a) usually quite short, much less than the width of the sidebar; but also (b) sometimes very long, e.g. a full sentence, so that they don't even fit the sidebar and will themselves be truncated.
Created attachment 194645 [details] Patch with gtk3
Created attachment 194646 [details] Patch with kf6 Too many issues (see comments on Gerrit plus the fact that hover effects are missing for non-gtk VCL) and not much improvements (plus less acceptance from users). Abandoned the patch https://gerrit.libreoffice.org/c/core/+/168476
(In reply to Heiko Tietze from comment #9) > Created attachment 194646 [details] > Patch with kf6 > > Too many issues (see comments on Gerrit plus the fact that hover effects are > missing for non-gtk VCL) and not much improvements (plus less acceptance > from users). Abandoned the patch > https://gerrit.libreoffice.org/c/core/+/168476 It may be possible to make the row space behavior of the SalInstanceTreeView (x11, qt, windows, maybe mac) the same as the GtkInstanceTreeView. Even without the same behavior +1 from me for using your rounded rectangle idea.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/35d42ca07159a7fa4958c35dba05c527f3be29e6 Partially resolves tdf#160540 Quickfind sidebar: make better use of It will be available in 25.2.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.
(In reply to Jim Raykowski from comment #10) > Even without the same behavior +1 from me for using your rounded rectangle > idea. Why have an additional rounded rectangle at all? Isn’t it enough with the blue highlight to tell items apart? What am I missing?
Created attachment 194940 [details] with and without round rectangle comparison (In reply to Adolfo Jayme Barrientos from comment #12) > Why have an additional rounded rectangle at all? Isn’t it enough with the > blue highlight to tell items apart? What am I missing? Personally I like the round rectangle around each of the search finds but I'm not against removing it.
The (rounded) rectangle gives the list structure. It needs a bit more spacing and the border must not use strong colors - the view is overly busy now - but in general it's an improvement.