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 Expected result: A workflow that allow interacting with the content (the text document) without a stolen focus and window popping up in from of the content. Actual result: 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. Suggested solution: 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.
Hi Björn, I like this one with only one condition: that short cuts keep working as we know now. Thanks! Cot
Are there any code pointers for this bug?
Code Pointers: The current Find and Replace Dialog is SvxSeachDialog in svx/source/dialog/srchdlg.cxx: http://docs.libreoffice.org/svx/html/classSvxSearchDialog.html As for making an existing dialog into a sidebar panel, the navigator panel might give some orientation: http://opengrok.libreoffice.org/search?q=NavigatorPanel&project=core&defs=&refs=&path=&hist=
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp TopicUI) [NinjaEdit]
*** 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) [NinjaEdit]
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. Thanks!
Hi Steven, 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. http://2.bp.blogspot.com/-I-3zFgVtWXU/UXkhWWCfZ9I/AAAAAAAABJ8/4savFViARIs/s1600/01-Find+&+Replace+Dialog+Box+with+Find+tab+selected.png
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 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Interesting topic for GSoC.
*** Bug 147033 has been marked as a duplicate of this bug. ***
Created attachment 184862 [details] Mockup
To summarize the requirements: a) move the "find all" functionality from the quickfind bar into a new sidebar deck b) show some words before/after the reference c) jump to the place on click d) clearly identify the currently selected reference Some questions remain open resp. needs discussion: a) The ticket requests "find & replace" but I believe the competitors decided to have replacement functionality for good reasons in an extra dialog. My take here is to keep it simple and just replicate the quick find bar into a sidebar deck. b) What happens if a words occurs multiple time in a range? We could show every single item (MSO does this) or summarize into one result (as shown in the mockup). c and d) The current quickfind function highlights all places until one iterates over it via next/previous; MSO uses a different shading for the currently active result, the mockup has a frame in highlight color / blue around the find result. a) The quickfind has the option to run a case sensitive search (and users asked repeatedly for more options). If we decide to add this option/s to the sidebar deck, it should remain simple. Could imagine a toggle button next to the search field. The competitors allow to search for headings (limits the search to outlines), pages (shows thumbnail of pages where the item was found), and results. I think this is not needed.
@Jim, Samuel, Heiko -- using the SB framework would need to pick a target Deck to place a new Content panel for the "Quick find" results. So, place it into an existing SB Deck, or should this be a new "Search" Deck that would hold find related Content panels? Starting with a Content panel showing result of "Quick find" Find Bar as in attachment 184862 [details] Regards layout on the content panel, would the "results" being shown be "clipped" from the document (with full styling/formatting) --or should result be more simple unformatted text runs for a cleaner UI? Personally, I'd prefer no formatting. And could the hyperlinking to the results be available to manipulate (e.g. turn a selected search result into a reference or a bookmark). But also what would a content panel holding elements for the full "Find and Replace" dialog provide? Could the full dialog be eliminated? Or the Content panel would just show results? Likewise, would this new SB work--Deck and Content Panel(s)-- to also enter and display find/search result for the HUD for the "Command search" (bug 91874 and bug 151228)
(In reply to Heiko Tietze from comment #27) > b) What happens if a words occurs multiple time in a range? We could show > every single item (MSO does this) or summarize into one result (as shown in > the mockup). Having individual listings for all finds would be better for context menu actions like the hyperlinks to results enhancement Stuart has suggested. > c and d) The current quickfind function highlights all places until one > iterates over it via next/previous; MSO uses a different shading for the > currently active result, the mockup has a frame in highlight color / blue > around the find result. Perhaps like what has been done for enhancement bug 152029, find results could have an inverted overlay if in the visible display area when the mouse is placed over entries in the content list. Navigating to an entry could be made to not clear all find selections as opposed to how the find bar clears the selections when stepping through results. > a) The quickfind has the option to run a case sensitive search (and users > asked repeatedly for more options). If we decide to add this option/s to the > sidebar deck, it should remain simple. Could imagine a toggle button next to > the search field. Check buttons could be placed under the search term input box like the find and replace dialog has for 'match case' and 'whole words only options'. (In reply to V Stuart Foote from comment #28) > So, place it into an existing SB Deck, or should this be a new "Search" Deck > that would hold find related Content panels? Starting with a Content panel > showing result of "Quick find" Find Bar as in attachment 184862 [details] One deck that contains a quick find panel and find and replace panel seems like a good idea to me. Someday it might be possible for users to create custom decks with any panels they want to place in them ;-) > Regards layout on the content panel, would the "results" being shown be > "clipped" from the document (with full styling/formatting) --or should > result be more simple unformatted text runs for a cleaner UI? Personally, > I'd prefer no formatting. A checkbox for how to display results might work for this. > And could the hyperlinking to the results be available to manipulate (e.g. > turn a selected search result into a reference or a bookmark). If I'm following, this would be done through a context menu. Sounds like a nice enhancement. > But also what would a content panel holding elements for the full "Find and > Replace" dialog provide? Could the full dialog be eliminated? Or the Content > panel would just show results? The full find and replace dialog can be placed in the sidebar. Some ui changes could be done to make it more panel appropriate. The dialog version could be eliminated but it wouldn't be required to for the panel version to exist. > Likewise, would this new SB work--Deck and Content Panel(s)-- to also enter > and display find/search result for the HUD for the "Command search" (bug > 91874 and bug 151228) Nice! I didn't know about the command search HUD. Seems like it would be appropriate as a panel in a find deck.
Hi, I want to work on this bug as my GSoC project but i'm lacking some knowledge about how to implement the idea like how to make a dialog into a sidebar deck/panel. could you please provide some guidance ? thanks.
(In reply to MoazAlaa from comment #30) > Hi, I want to work on this bug as my GSoC project but i'm lacking some > knowledge about how to implement the idea like how to make a dialog into a > sidebar deck/panel. could you please provide some guidance ? > thanks. Please contact the mentors listed on the ideas page. Before you contact them, however, do your research and in your email explain what you have learned and where you are stuck. Your current question is not in good style.
*** Bug 158422 has been marked as a duplicate of this bug. ***
Upping priority since there are 6 duplicates.
(In reply to Heiko Tietze from comment #26) > Created attachment 184862 [details] > Mockup As someone who prefers an uncluttered document space, I prefer a dialog solution. Some close sibling of the Navigator window would be perfect.
https://gerrit.libreoffice.org/c/core/+/160500 and https://gerrit.libreoffice.org/c/core/+/160422 are in the works.
khushishikhu committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9338f87a6644e9b2309c3a009af096e38fbb107e tdf#95405 Sidebar: Quick Find for writer It will be available in 24.8.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.
I tested this new feature. But I found the brackets distracting. Would not be bolding the word much better? I build myself this version, is not yet released. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9338f87a6644e9b2309c3a009af096e38fbb107e CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded