Created attachment 120066 [details]
search results in evince 3.16.1
Steps to reproduce:
1/ open writer, type dt<F3> to get some text
2/ Open menu Edit->Find and Replace
A workflow that allow interacting with the content (the text document) without a stolen focus and window popping up in from of the content.
A dialog pops up directly over the document that we want to edit/search/work on and steal the focus. As a bonus, this dialog has to be moved out of the way almost every time as it blocks the view to the document it operates on.
Make the whole search and replace dialog a deck in the sidebar, for a start just containing the controls of the current dialog. This would open by clicking the menu entry, but ensure the find and replace UI would not block the view on the document it operates on, neither needing to steal focus.
Optional further extensions:
Make the sidebar contain matches of the search below the controls as e.g. the PDF-viewer "evince" does. An example screenshot is attached.
Find (ctrl+F) is non-modal via toolbar. Find & Replace should work similar, maybe like the stacked/expanded input in Kate (https://docs.kde.org/trunk4/en/kde-runtime/fundamentals/find.html). Of course we could also move the search functionality completely into the sidebar, which would affect all components.
I like this one with only one condition: that short cuts keep working as we know now.
Are there any code pointers for this bug?
The current Find and Replace Dialog is SvxSeachDialog in svx/source/dialog/srchdlg.cxx:
As for making an existing dialog into a sidebar panel, the navigator panel might give some orientation:
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp TopicUI)
*** Bug 96394 has been marked as a duplicate of this bug. ***
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
So i do agree that we should have find & replace as a section in the sidebar, i dont think killing off the existing dialog is a good thing, especially for users who cant use the sidebar due to screen size limitations.
Just wondering if the following is a correct interpretation of the task:
1) Create find/replace section in sidebar.
2) Leave current find/replace dialogue in place.
Yes having the functionality in both places are ideal at the moment, so they both should be running off the same code, just like we have now for Navigator. The design team would need to work on a mockup for it.
(this already was filed in issue 45095)
*** Bug 45095 has been marked as a duplicate of this bug. ***
(In reply to Cor Nouws from comment #11)
> (this already was filed in issue 45095)
Wouldnt say docking the find and replace is equivalent to having a deck in the sidebar, but whatever. :D
(In reply to Yousuf (Jay) Philips from comment #10)
> Yes having the functionality in both places are ideal at the moment, so they
> both should be running off the same code, just like we have now for
> Navigator. The design team would need to work on a mockup for it.
Yes and the "at the moment" means that like the Navigator dialog (<F5>), the Find & Replace dialog (<Ctr>+H) will need to continue to be available independent of the Sidebar instance. Unlike the old Styles & Formatting dialog (<F11>) that was bound into the Sidebar.
But this resolves with implementation of bug 85905 -- Allow undocking of Sidebar Decks. With that any of the Content panels could be detached to function as floating dialogs or be attached to additional docking points (as is done for independent Navigator dialog now). An implementation issue, but functionally there would only be one of each Content panel set (as controlled from the Button bar) with multiple Deck containers to hold each as detached.
So for now, the task is implementing the Find & Replace .ui dialog into a Sidebar Content panel context. And providing it with the same handling as the independent Navigator Content panel.
Created attachment 123443 [details]
Find panel in MS Office
So here is a screenshot of the Find/Navigate panel in MS Word 2013, it is what you get when you click the find button in the ribbon, as the panel has limited find functionality, so they still retain the find/replace/goto dialog.
In Keynote, Pages and Numbers, the Search window appears floating over the document being edited, it never appears in the sidebar. See enclosed screenshot.
Created attachment 123488 [details]
Screenshot of string search window in OSX productivity apps
Created attachment 123489 [details]
Cog dropdown menu (search options)
As one can see from the screenshot, the search options are hidden in a dropdown menu to the left of the window
The OSX search dialog remembers the option last chosen when it is next opened. In other words, if the dialog was displayed as search and replace, it will do so again after dismissal and re-opening.
Created attachment 123694 [details]
Find and replaec dialog
*** Bug 87998 has been marked as a duplicate of this bug. ***
*** Bug 124634 has been marked as a duplicate of this bug. ***
Please add keyword 'needsUXEval' and CC 'firstname.lastname@example.org' if input from UX is needed.
Interesting topic for GSoC.
*** Bug 147033 has been marked as a duplicate of this bug. ***