Follow-up to bug 95405: The sidebar is supposed to be an improvement to the classic toolbar. We should default the quicksearch to this control - and have the legacy toolbar as an alternative option. Could be Tools > Options > Writer > View: Default Quick Find (o) Sidebar ( ) Toolbar
The new Quick find deck is not a replacement for the "Find and Replace" dialog, and it is only a supplement to current <Ctrl>+F Find bar, and "Repeat find" from the Navigator (it reused common code). The quick find was tracked with proposal of bug 95405, but thus far does not address the full feature set of the <Ctrl>+G dialog which would require an entirely new content panel. See no advantage ATM to forcing <Ctrl>+F to the Sidebar deck.
Talking about quickfind (ctrl+F) only. Ctrl+G or H should remain at the F&R dialog.
(In reply to Heiko Tietze from comment #2) > ... Ctrl+G or H should remain at the F&R dialog. Yes, <Ctrl>+H (sorry my typo). <Ctrl>+G of course is the "Go to..." page dialog. NTL don't think the SB Quick find deck is ready for default use--especially with out a corresponding F&R content panel worked up.
The quickfind works as follows: - Ctrl+F <find foo> ESC => all as before. Will that also be the case with Find in de sidebar? Will ESC bring the sidebar to the state of before hitting Ctrl+F?
I'd just keep the sidebar open, but Ctrl+F5 or F11 both toggle the sidebar.
(In reply to Heiko Tietze from comment #5) > I'd just keep the sidebar open, but Ctrl+F5 or F11 both toggle the sidebar. So that looks as if it would interrupt possibly work (based on some selection, collapsed panels..) in the sidebar?
set to NEW as a valid enhancement
(In reply to Cor Nouws from comment #6) > (In reply to Heiko Tietze from comment #5) > > I'd just keep the sidebar open, but Ctrl+F5 or F11 both toggle the sidebar. > > So that looks as if it would interrupt possibly work (based on some > selection, collapsed panels..) in the sidebar? IMO this needs to be sorted out before this gets implemented.
(In reply to Cor Nouws from comment #8) > (In reply to Cor Nouws from comment #6) > > (In reply to Heiko Tietze from comment #5) > > > I'd just keep the sidebar open, but Ctrl+F5 or F11 both toggle the sidebar. > > > > So that looks as if it would interrupt possibly work (based on some > > selection, collapsed panels..) in the sidebar? > IMO this needs to be sorted out before this gets implemented. I'm fine with toggle as well as to keep the sidebar open (command just opens).
(In reply to Heiko Tietze from comment #9) > I'm fine with toggle as well as to keep the sidebar open (command just > opens). You mean that you accept that the status/situation etc of the Sidebar changes when you use Ctrl+F for search? If so: I am not, but could leave with an expert option that allows me to keep the current behavior :)
(In reply to Cor Nouws from comment #10) > If so: I am not, but could leave with an expert option that allows me to > keep the current behavior :) Sight, should be: If so: "I do not, but could live with ..."
I think it's worth to discuss this again before someone puts his/her hands on this. See previous comments
Too much remains to be done on the SB content panels for a replacement of the Find bar (<Ctrl>+F) TB, with even more needed to supplement/replace the <Ctrl>+H "Find and Replace..." dialog. Also, as a normal TB the Find bar can be undocked, supporting workflows where that is useful. While the *entire& SB would have to be undocked (absent the work needed for bug 85905) or the quick find replicated (like the Navigator) using SB framework. Just not an appealing UI.
(In reply to V Stuart Foote from comment #13) > Too much remains to be done on the SB content panels... What exactly is the blocker? > Just not an appealing UI. Maybe but a much superior workflow.
Hmm, lets count them up: Functional shortfalls 1. always performs a 'find all', with no 'next' 'previous' 2. always performs transliterated string search, no 'Match Case' 3. no button link to the full 'Find and Replace...' dialog 4. no results infobar 'Search key found # times' UI short falls 1. the find returns the matches embedded in a wall of text, with brackets around the match rather than highlights 2. the string enclosing the match is unpredictable, should use a ICU break iterator to start and end result string on sentence, or a clause break 3. for matches too numerous to fit, truncate the Content deck list box to single line--no wrap, each match centered in the content panel 4. mouse click navigation between the matches, just cursor U,D button movement; content panel needs same Navigate buttons as the Navigator 5. when matches span more than one page, the on page visual highlights alone don't give sufficient feedback--need match details (maybe Para, Page, Document) as a content panel.
(In reply to Heiko Tietze from comment #14) > Maybe but a much superior workflow. I still miss reflection on what IMO will be a horrible outcome of the work as it is envisioned now: after using Ctrl+F for search, the status/situation etc of the Sidebar is changed, meaning the user would need to manually re-establish that state, while currently Ctrl+F .. <find> .. ESC leaves all other UI elements as is.
(In reply to Cor Nouws from comment #16) >... after using Ctrl+F for search, the status/situation > etc of the Sidebar is changed, meaning the user would need to manually > re-establish that state, while currently Ctrl+F .. <find> .. ESC leaves all > other UI elements as is. Not sure about that, we have shortcut/accelerators for each of the SB decks, <Alt>1-9, or <F11> for the Stylist--or a mouse click selection on the SB deck buttons. So can just pop back to the deck needed, simply leaving the Find deck. No more involved than using the <Esc> now from the Find bar.
(In reply to V Stuart Foote from comment #17) > Not sure about that, we have shortcut/accelerators for each of the SB decks, > <Alt>1-9, or <F11> for the Stylist--or a mouse click selection on the SB > deck buttons. So can just pop back to the deck needed, simply leaving the > Find deck. No more involved than using the <Esc> now from the Find bar. Almost as simple, since the focus/selection in the pane changes (at least for me).
(In reply to Heiko Tietze from comment #0) > Follow-up to bug 95405: The sidebar is supposed to be an improvement to the > classic toolbar. We should default the quicksearch to this control - and > have the legacy toolbar as an alternative option. When we have a decent search sidebar, then let's talk about that. Fix some of its bugs (I'm going to file a couple after my first single use), add some of the Find dialog functionality, etc... So, for now, definite no-no from me. Even in principle I'm not sure I would support this, because the sidebar takes a huge chunk of your viewport away, while the find bar is just a vertical bar, and at the bottom where it's less noticeable than a top toolbar.
We discussed the topic in the design meeting. Most participants shared the view of an unfinished state but agreed on the option. It should consequently remain on the toolbar.
(In reply to Heiko Tietze from comment #20) > Most participants shared the view of an unfinished state but agreed on the > option. While I can't badmouth opt-in optional functionality, I quite doubt the usefulness of this. I don't see the "superior workflow" Heiko mentions. Anyway, adding a couple of glaring bugs before the resolution of which this option absolutely doesn't make sense.
(In reply to Eyal Rozenberg from comment #21) > Anyway, adding a couple of glaring bugs before the resolution of which this > option absolutely doesn't make sense. Thanks for digging BZ but better add these as See Also.