Style lists in the sidebar can be very long - so much so as to make them inconvenient to search through. Just like we can type in parts of names in other parts of the UI we use to search long lists (like Insert Cross-Reference) - the user should be able to type in part of the style name and have the list filtered according to this typing. Naturally, some way to focus the list or the sidebar would be necessary for this typing to "take".
Looks like a dup of https://bugs.documentfoundation.org/show_bug.cgi?id=114886 maybe others https://bugs.documentfoundation.org/buglist.cgi?quicksearch=styles%20filter&list_id=1599835
(In reply to m.a.riosv from comment #1) > Looks like a dup of > https://bugs.documentfoundation.org/show_bug.cgi?id=114886 Absolutely not a dupe of that. Nowhere does that suggest filtering by style name that's typed in the sidebar. > maybe others > https://bugs.documentfoundation.org/buglist. > cgi?quicksearch=styles%20filter&list_id=1599835 I'll have a look.
I can filter by typing the name, as long as I've clicked in the list first, in: Version: 7.4.7.2 / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded What OS / DE are you using?
(In reply to Stéphane Guillou (stragu) from comment #3) > I can filter by typing the name, as long as I've clicked in the list first, So, 1. I want this without having clicked a list item first, although that's not a critical part of the ask. 2. When I click a list item and type, the list scrolls to the first match for what I've typed, it doesn't filter. > What OS / DE are you using? Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Calc: threaded
(In reply to Eyal Rozenberg from comment #4) > 1. I want this without having clicked a list item first, although that's not > a critical part of the ask. Reminds me of bug 154994. There's the question of "should toggling a UI element move the keyboard focus off the page?" As I noted in bug 154994 comment 2, the Gallery and Navigator decks already do that. > 2. When I click a list item and type, the list scrolls to the first match > for what I've typed, it doesn't filter. Similar to bug 122718 for functions.
I hesitate to welcome enhancement requests that make this UI more complex (like in bug 141483). Nevertheless adding a filter type "by name" that shows the envisioned input field solves the problem to find a particular style and would not be annoying for most users. => NEW Still prefer to not implement such thing as the use case is weak. Who _filters_ the list of styles by name? If you don't find "List*", for example, quickly the currently implemented filter provides a List Styles option (and could do similar for other types if something is missing). In other words I would rather invest effort in a shorter list than management functions. => WF And last bit not least a dedicated dialog for style management is requested in bug 90646 that could offer more options. => DUP
(In reply to Heiko Tietze from comment #6) > I hesitate to welcome enhancement requests that make this UI more complex > (like in bug 141483). Well, the set style drop down in toolbar could be modified to do this, I think Mimicking the behaviour of the Font Name drop down So click the drop down to expand the list. And type & find style, similar to find font. The drop down list currently lists a default set of styles. There are two options: * Leave this as it, however typing a paragraph style name does find a style by name * List all styles (cluttering the UI, personally not in favor of this) Somewhat related: bug 155729 Note: the proposal is limited to 'Paragraph Styles'. The character styles equivalent would mean introducing a new drop down for character styles (which can added to the UI customization options)
(In reply to Heiko Tietze from comment #6) Note that, unless you start typing in the style list, the (visible) UI doesn't change. So the complexity is hidden > Still prefer to not implement such thing as the use case is weak. Who > _filters_ the list of styles by name? I do... the default list of styles has 4 pages' worth of items on my PC's monitor, and on my laptop - nearly double that. But the more common use case for me is when I've opened an MS Word file, and I get a bunch of auto-generated styles there, which all begin with a similar prefix. > And last bit not least a dedicated dialog for style management is requested > in bug 90646 that could offer more options. If that were implemented, I'd want filtering-by-typing both for the modal dialog for style management, _and_ for the sidebar for style use and indication of what style is at the cursor (+ colored highlighting).
See also bug 130646, which also asks for a filter for bookmarks in navigator. I agree we could replace the current sidebar search functionality with a filter that only lists matches, including partial – which wouldn't add complexity. What should happen once leaving the text box? The filter should persist, or should it directly be reset? I assume reset, just like currently.
(In reply to Stéphane Guillou (stragu) from comment #9) > What should happen once leaving the text box? The filter should persist, or > should it directly be reset? I assume reset, just like currently. I'm not sure. What if I leave the textbox because I want to walk the match list one by one? Perhaps even walk, try, and maybe try another one from the same list? Note sure. Can you explain what you're referring to by "currently", when we don't have a filtering textbox?
(In reply to Eyal Rozenberg from comment #10) > Can you explain what you're referring to by "currently", when we don't have > a filtering textbox? I mean the current search box that pops up when the style list is focused and the user starts typing. Noting that the current search functionality allows the user to navigate the matches with keyboard arrows, which I think is useful and we shouldn't lose if we change it to a filter.
(In reply to Stéphane Guillou (stragu) from comment #11) > I mean the current search box that pops up when the style list is focused > and the user starts typing. > Noting that the current search functionality allows the user to navigate the > matches with keyboard arrows, which I think is useful and we shouldn't lose > if we change it to a filter. Ah, this might only be true for gtk3. Didn't realise it was so different between VCLs.
(In reply to Stéphane Guillou (stragu) from comment #11) > I mean the current search box that pops up when the style list is focused > and the user starts typing. > Noting that the current search functionality allows the user to navigate the > matches with keyboard arrows, which I think is useful and we shouldn't lose > if we change it to a filter. Hmm... interesting question. Options: 1. Suppress the pop-up, have typing continue any typing in the top-of-list text box? 2. Keep text and filtering from the top box, have the popup function within the filtered list. 3. Clear the top box typing, have the pop-up search the unfiltered list.