Created attachment 61600 [details] Mockup of the search field in options window LibreOffice has a lot of options, and it's sometimes difficult to find one in particular. Currently, the best way to find it is to use the local Help database. It would be great to have a small "Search" field that would automatically hide the options in the tree that don't match the entered keywords, as seen in vlc or eclipse.
This would be incredibly useful. Making this HIGHEST ENHANCEMENT.
This sounds a bit interesting to me, and I can see the usefulness of it. I personally probably don't have much time to devote to it right now though. If the community wants it and no one else gets to it, I may look into this a couple of months.
(In reply to comment #2) > I may look into this a couple of months. in a couple of months
Thorsten has an about:config like plugin to make it possible to see all settings, even hidden ones - that this might fit into quite well. It's hard to see how to present search results with the existing UI in a familiar way. ie. this needs some serious UX input before actioning :-)
I think eclipse is a good example for this, it has exactly this search field implemented. If you search in the three left all is hidden which don't contain the keyword, but not only in the name, all field names are searched within the pages. Screenshot: (found with google) http://tuxanddroid.de/wp-content/uploads/2010/10/eclipse_settings.png You can try it out if you test it in eclipse...
Agree that this would be a great feature. Also agree that it takes pretty serious work to change the UI.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
Adding self to CC if not already on
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
*** Bug 121160 has been marked as a duplicate of this bug. ***
*** Bug 122882 has been marked as a duplicate of this bug. ***
Changing priority back to 'medium' since the number of duplicates is lower than 5
Still a fine idea. Somewhat unnecessary for power users since advanced options has a search now.
Hi all, I'll work on this enhancement and I need some code pointers. I'd appreciate it if you could share some pointers/steps/suggestions. Thanks in advance.
No code pointer but an additional idea: we could steal from KDE and show modified options with some special indicator- for me using Breeze Dark the frame around controls becomes orange and list items get an orange dot. Better to discuss this idea in a separate ticket but it could be a fall-out from this search project. UI-wise I would dim items that are not a result of the search or parent of an item. For example, if you find <Foo> in a label or a tooltip this control, its parent container, and the tree item keep the contrast while any other control and label is reduced by 50% or so. Sounds as if you need to generate a list of items with content from all ui files [1] (some data might be instantiated when loaded; no idea how to tackle this) and search over this structure. [1] cui/uiconfig/ui/opt*.ui (not sure every option page is named like this)
Hi Bayram! The menu options are set in treeopt.hrc [1] and build in treeopt.cxx [2]. Maybe you can get some inspiration from [3]. I could imagine an interface/method implemented by all the dialogs which allows to search for a specific string and to emphasize the menu settings in the various dialogs something like in OfaTreeOptionsDialog::ResetCurrentPageFromConfig() (reset function). This would allow to customize the search for every dialog. You may start by searching the treeview and expanding the search functionality for every single dialog step by step. [1] https://opengrok.libreoffice.org/xref/core/cui/inc/treeopt.hrc?r=e20d2de7#147 [2] https://opengrok.libreoffice.org/xref/core/cui/source/options/treeopt.cxx?r=116b9d6d#1319 [3] https://gerrit.libreoffice.org/c/core/+/115380
Additional information may be found in the see also section of this bug.
patch https://gerrit.libreoffice.org/c/core/+/152519 is still WIP, but needs test/review and feedback. Thanks!
Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4633dadb4233ad5587bd238449671d610540c81 tdf#49895: Add search functionality to Options dialog It will be available in 24.2.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.
Wow! This feature is so nice! I tried to test this with the word "port". It's ok for Internet, in the submenu Proxy there are 3 "Port:". But why on LibreOffice - Accesibility? There is nothing with "port". Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cf1cdc00e1e2d2684cfe57ac002a37c5f3d100c5 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #20) > Wow! This feature is so nice! > > I tried to test this with the word "port". It's ok for Internet, in the > submenu Proxy there are 3 "Port:". But why on LibreOffice - Accesibility? > There is nothing with "port". > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: cf1cdc00e1e2d2684cfe57ac002a37c5f3d100c5 > CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 > Locale: ro-RO (ro_RO.UTF-8); UI: en-US > Calc: threaded Hi BogdanB, There is "support" in the first check button that includes "port" word. Search function can show the results of the words that are inside another words. We don't only check the whole word, but also check if the word is inside another word. Additionally, we don't check the visibility of the items in the dialogs - due to some technical reasons(maybe this can be possible in the next versions of the search function). In the future improvements, "accessible-names", "accessible-descriptions" and "tooltip-texts" will also be included into searching. Therefore, the search term may not be present (or visible) in dialogs - which is fine at the moment. (But of course we can change the behavior of the search function at any time, if it's needed) For example: please search "father" term. It will show the "User data" dialog. On my computer, there is no items include "father" keyword. But actually it is present in the UI (with id "rusnameft" and with label "Last/first/father’s name/initials:"). Therefore, it will show the "User data" dialog in the results without the visibility check. I'm open to any suggestions to improve the search functionality. Thanks.
Created attachment 189270 [details] screenshot No "support" on Accessibility windows. But maybe it is like you said, it's something not visible, but searchable.
Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c68e1dca3a5a06248ce129bfb13206753163d71d tdf#49895: show wait cursor while Options dialog loads It will be available in 24.2.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.
Some bits might be missing but we can close this ticket as fixed/done. Thanks a lot, Bayram.
Bayram Çiçek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0eb05b47a6d89fdfc533515483584fc739962b65 tdf#49895: search in Options: check if label exists (related to tdf#157266) It will be available in 24.2.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.
Needs to be added to release notes, I believe.
(In reply to Mike Kaganski from comment #26) > Needs to be added to release notes, I believe. I added to: https://wiki.documentfoundation.org/ReleaseNotes/24.2#Core_/_General Thanks!
Taichi Haradaguchi committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2c71560cf64499365e803f710c788d033da0e5e9 Related tdf#49895: Mark strings as translatable It will be available in 24.2.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.
Thanks, verified in: Version: 24.2.0.2 (X86_64) / LibreOffice Community Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
@Bayram Çiçek It seems your patch slowed down loading the options dialog noticeably. https://git.libreoffice.org/core/+/a4633dadb4233ad5587bd238449671d610540c81%5E%21 With LibreOffice-24.2 it's about 10 times slower than with LibreOffice-7.6. (before LibreOffice-7.1 the options loaded slow because of bug 146852) It's not a disaster. But on slower computers you really have to wait multiple seconds since LibreOffice-24.2. I guess on older computers this can exceed 10 seconds while being 1 second in LibreOffice-7.6. Reproduction: Tools -> Options Measure the time until the Options window is opened. NOTE: It's just the first time the Options are being opened after starting LibreOffice. For repeating the test you have to restart LibreOffice. I've tested exactly your commit using this Git repo with binaries. https://bibisect.libreoffice.org/linux-64-24.2.git See also: https://wiki.documentfoundation.org/QA/Bibisect The binary commit 418e06688 in that repo corresponds to the a4633dadb commit in https://git.libreoffice.org/core/ 418e06688^ is fast and 418e06688 is slow. On my Ryzen-5650U @ 2.3 GHz (4.2 GHz boost) notebook CPU it's just half a second. But if I slow down the CPU to the minimum of 1.6 GHz and disable the boost it's already over a second. While LibreOffice-7.6 stays nicely below half a second. /sys/devices/system/cpu/cpufreq/boost /sys/devices/system/cpu/cpu*/cpufreq/{boost,scaling_max_freq} I've got a low power Celeron-J4105 CPU system on which it's below 1 second with 418e06688^ and over 4 seconds with 418e06688 If I throttle the CPU to 800 MHz 418e06688^ stays below 1 second while 418e06688 needs over 8 seconds. And I guess on a Raspberry Pi 4 or 5 used as a desktop computer it's even slower. Even on high speed CPUs you can see it clearly if you "cpulimit" to limit the computing power available to the process. On my Ryzen-5650U limited to 1.6 GHz with boost disabled this is over 8 seconds with 418e06688 https://packages.debian.org/bookworm/cpulimit # first shell (limit process to CPU core 0) soffice # second shell sudo cpulimit -fv -l2 -e soffice.bin Operating system on all machines: Debian-12 Same results for Upstream-LibreOffice-7.6, Debian-12-LibreOffice-7.4 and LibreOffice 418e06688^ The problem seems to boil down to this eager preloading. initializeFirstNDialog(25); https://git.libreoffice.org/core/+/3b50600e8f817409f5a21249871d9f82728e4987/cui/source/options/treeopt.cxx#1201 Although if I reduce the number from 25 to 1, I get a strange effect that didn't exist in 418e06688^. Some sections in the options dialog like LibreOffice->View get loaded really slow when clicking them. But not all sections are affected. So I'd consider removing this preloading (equivalent to setting the value to 1) less bad than the situation since LibreOffice-24.2. Because then you've only have to wait when clicking one of the slow sections or when using the search function (initializing the search takes some time with a value of 1). Ideally a user would only have to wait when using the new search feature. But I haven't figured out yet if or how that's possible. (very ideally a user never has to wait ;-) but I guess the new search feature just needs time to initialize)
(In reply to kolAflash from comment #30) > @Bayram Çiçek > > It seems your patch slowed down loading the options dialog noticeably. > https://git.libreoffice.org/core/+/ > a4633dadb4233ad5587bd238449671d610540c81%5E%21 > With LibreOffice-24.2 it's about 10 times slower than with LibreOffice-7.6. > (before LibreOffice-7.1 the options loaded slow because of bug 146852) > > It's not a disaster. But on slower computers you really have to wait > multiple seconds since LibreOffice-24.2. I guess on older computers this can > exceed 10 seconds while being 1 second in LibreOffice-7.6. > > > > Reproduction: > Tools -> Options > Measure the time until the Options window is opened. > NOTE: > It's just the first time the Options are being opened after starting > LibreOffice. For repeating the test you have to restart LibreOffice. > > I've tested exactly your commit using this Git repo with binaries. > https://bibisect.libreoffice.org/linux-64-24.2.git > See also: https://wiki.documentfoundation.org/QA/Bibisect > The binary commit 418e06688 in that repo corresponds to the a4633dadb commit > in https://git.libreoffice.org/core/ > 418e06688^ is fast and 418e06688 is slow. > > On my Ryzen-5650U @ 2.3 GHz (4.2 GHz boost) notebook CPU it's just half a > second. But if I slow down the CPU to the minimum of 1.6 GHz and disable the > boost it's already over a second. While LibreOffice-7.6 stays nicely below > half a second. > /sys/devices/system/cpu/cpufreq/boost > /sys/devices/system/cpu/cpu*/cpufreq/{boost,scaling_max_freq} > > I've got a low power Celeron-J4105 CPU system on which it's below 1 second > with 418e06688^ and over 4 seconds with 418e06688 > If I throttle the CPU to 800 MHz 418e06688^ stays below 1 second while > 418e06688 needs over 8 seconds. > And I guess on a Raspberry Pi 4 or 5 used as a desktop computer it's even > slower. > > Even on high speed CPUs you can see it clearly if you "cpulimit" to limit > the computing power available to the process. On my Ryzen-5650U limited to > 1.6 GHz with boost disabled this is over 8 seconds with 418e06688 > https://packages.debian.org/bookworm/cpulimit > # first shell (limit process to CPU core 0) > soffice > # second shell > sudo cpulimit -fv -l2 -e soffice.bin > > Operating system on all machines: Debian-12 > Same results for Upstream-LibreOffice-7.6, Debian-12-LibreOffice-7.4 and > LibreOffice 418e06688^ > > > > The problem seems to boil down to this eager preloading. > initializeFirstNDialog(25); > https://git.libreoffice.org/core/+/3b50600e8f817409f5a21249871d9f82728e4987/ > cui/source/options/treeopt.cxx#1201 > Although if I reduce the number from 25 to 1, I get a strange effect that > didn't exist in 418e06688^. Some sections in the options dialog like > LibreOffice->View get loaded really slow when clicking them. But not all > sections are affected. > > So I'd consider removing this preloading (equivalent to setting the value to > 1) less bad than the situation since LibreOffice-24.2. Because then you've > only have to wait when clicking one of the slow sections or when using the > search function (initializing the search takes some time with a value of 1). > > Ideally a user would only have to wait when using the new search feature. > But I haven't figured out yet if or how that's possible. > (very ideally a user never has to wait ;-) but I guess the new search > feature just needs time to initialize) We have a bug report for that issue. let's please continue our discussion on the bug page - as I replied this comment there: https://bugs.documentfoundation.org/show_bug.cgi?id=159375#c14