Bug 160999 - Find sidebar results presented with huge gratuitous spaces
Summary: Find sidebar results presented with huge gratuitous spaces
Status: RESOLVED DUPLICATE of bug 160540
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-08 22:30 UTC by Eyal Rozenberg
Modified: 2024-06-06 05:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Document in which searching triggers the bug (12.37 KB, application/vnd.oasis.opendocument.text)
2024-05-08 22:30 UTC, Eyal Rozenberg
Details
Spaced-out results of search in document from attachment 194036 (129.57 KB, image/png)
2024-05-08 22:33 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-05-08 22:30:13 UTC
Created attachment 194036 [details]
Document in which searching triggers the bug

Consider the attached document. 

If I:

1. Open the document in LO Writer
2. Open the Find sidebar
3. Search for the phrase "One"

I get several matches, as I should - but there's a huge amount of white-space between each match, which is not at all useful for me.

Seen with:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 92815f3a464b447898ecf52492247335228e4a72
CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: he-IL (en_IL); UI: en-US
Comment 1 Eyal Rozenberg 2024-05-08 22:33:20 UTC
Created attachment 194038 [details]
Spaced-out results of search in document from attachment 194036 [details]
Comment 2 Stéphane Guillou (stragu) 2024-05-09 02:44:48 UTC
Reproduced in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 92815f3a464b447898ecf52492247335228e4a72
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded
Comment 3 Buovjaga 2024-05-09 07:03:44 UTC
Khushi: can you take a look at this?
Comment 4 Khushi Gautam 2024-05-09 11:41:12 UTC
(In reply to Buovjaga from comment #3)
> Khushi: can you take a look at this?

Sure, I will look into this on weekend
Comment 5 Heiko Tietze 2024-05-27 09:40:39 UTC

*** This bug has been marked as a duplicate of bug 160540 ***
Comment 6 Eyal Rozenberg 2024-05-27 10:06:47 UTC
(In reply to Heiko Tietze from comment #5)
> 
> *** This bug has been marked as a duplicate of bug 160540 ***

I don't think this is a dupe - as, in my document, all search results are one line long, so the gratuitous space is not in order to unify the heights.
Comment 7 Buovjaga 2024-05-27 10:31:09 UTC
(In reply to Eyal Rozenberg from comment #6)
> (In reply to Heiko Tietze from comment #5)
> > 
> > *** This bug has been marked as a duplicate of bug 160540 ***
> 
> I don't think this is a dupe - as, in my document, all search results are
> one line long, so the gratuitous space is not in order to unify the heights.

It is still the same issue: fixed height. Heiko and you both want height that adapts to the search result content.
Comment 8 Eyal Rozenberg 2024-05-27 10:39:10 UTC Comment hidden (obsolete)
Comment 9 Eyal Rozenberg 2024-05-27 10:46:39 UTC
Actually... I'm not sure I mind the search results having uniform height. Let them all be one-line maybe. I just want it not to have empty spaces.
Comment 10 Buovjaga 2024-05-27 10:58:36 UTC
(In reply to Eyal Rozenberg from comment #9)
> Actually... I'm not sure I mind the search results having uniform height.
> Let them all be one-line maybe. I just want it not to have empty spaces.

Single line would be the only way to have uniform height without empty space. Are you now asking for the result strings to be truncated to max. the minimum width of the Sidebar? It seems awkward when you consider how long the search strings can be.
Comment 11 Eyal Rozenberg 2024-05-27 11:29:36 UTC
(In reply to Buovjaga from comment #10)
I'll first note that uniform width and variable width each have benefits and detriments. So, it's not as though I'm arguing uniform width is always superior in every way. That said...

> Single line would be the only way to have uniform height without empty
> space. 

1. Single line is not the only way to have uniform height with empty space - in a document that's longer than a few lines, as one can always grab more text from before and after the paragraph being searched (well, for document body search, not so much when searching captions, labels, comments and such.

2. I'm not necessarily against empty space. I would like a single line, I think, but given that context can be useful, I'd like this to be configurable. Maybe even configurable from within the sidebar itself! Just think of grep's --after-context and --before-context switches.

> Are you now asking for the result strings to be truncated to max. the
> minimum width of the Sidebar? 

3. Yes, when the height of the search result entry is fixed, I am asking that they be truncated; and if it's a single line - then yes, truncation to the width of the sidebar.

> It seems awkward when you consider how long the search strings can be.

4. Search strings are usually shorter than a sidebar length's worth. 

5. When you search for a long string, you're likely to want a longer context than the sidebar will show you anyway.

6. See (2.) - configurable height of result to the rescue! 

7. If your search string is _really_ long, three of four lines of height will not save you either, since just the search term itself may saturate the single-result area.

8. I say let the user see the start of the match, with the end of it possibly truncated.
Comment 12 Stéphane Guillou (stragu) 2024-06-05 04:24:10 UTC
Eyal, can we please have that discussion in bug 160540 instead of splitting it into two reports? The issue is that bug 160540 might get fixed without taking into account your ideas, ending up with an implementation that does not suit you.
We can make bug 160540 a tad more general, e.g. "Improve Find sidebar deck's use of space for results", to cover the whole issue. Then we can find a solution that suits everyone. I think you make good points and I don't want it to be lost and create frustration.
Comment 13 Eyal Rozenberg 2024-06-05 20:00:26 UTC
(In reply to Stéphane Guillou (stragu) from comment #12)

Do you really want to copy the whole discussion we've had here, over there? Would it not be better to write a more concise comment there indicating that a potential solution must take this bug into account as well?


If you really think unifying the two bug reports is the way to go, I'm ok with that, but then let's make it super-clear that there are two issues to address (e.g. with a new summary comment and a reference to it from the bug subject.)
Comment 14 QA Administrators 2024-06-06 03:17:36 UTC Comment hidden (obsolete)
Comment 15 Stéphane Guillou (stragu) 2024-06-06 05:55:10 UTC
(In reply to Eyal Rozenberg from comment #13) 
> Would it not be better to write a more concise comment there indicating that
> a potential solution must take this bug into account as well?
> If you really think unifying the two bug reports is the way to go, I'm ok
> with that, but then let's make it super-clear that there are two issues to
> address (e.g. with a new summary comment and a reference to it from the bug
> subject.)
Done.

*** This bug has been marked as a duplicate of bug 160540 ***