Bug 49895 - Add a "search" field in (non-advanced) Options dialog
Summary: Add a "search" field in (non-advanced) Options dialog
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Bayram Çiçek
URL:
Whiteboard: target:24.2.0 inReleaseNotes:24.2
Keywords:
: 121160 122882 (view as bug list)
Depends on:
Blocks: Options-Dialog
  Show dependency treegraph
 
Reported: 2012-05-14 02:07 UTC by Nicolas Toniazzi
Modified: 2024-04-30 18:48 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Mockup of the search field in options window (20.24 KB, image/png)
2012-05-14 02:07 UTC, Nicolas Toniazzi
Details
screenshot (105.59 KB, image/png)
2023-08-30 20:18 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Toniazzi 2012-05-14 02:07:32 UTC
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.
Comment 1 Joel Madero 2012-06-17 21:08:40 UTC
This would be incredibly useful. Making this HIGHEST ENHANCEMENT.
Comment 2 Daniel Bankston 2012-06-17 21:42:37 UTC
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.
Comment 3 Daniel Bankston 2012-06-18 01:01:01 UTC
(In reply to comment #2)
> I may look into this a couple of months.

in a couple of months
Comment 4 Michael Meeks 2012-06-26 04:17:48 UTC
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 :-)
Comment 5 Andreas B. 2012-07-24 08:23:33 UTC
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...
Comment 6 Kumāra 2013-02-07 08:55:10 UTC Comment hidden (me-too)
Comment 7 Björn Michaelsen 2014-01-17 00:43:50 UTC Comment hidden (noise)
Comment 8 Alex Thurgood 2015-01-03 17:38:14 UTC Comment hidden (noise)
Comment 9 Robinson Tryon (qubit) 2015-12-13 11:20:58 UTC Comment hidden (noise)
Comment 10 Heiko Tietze 2018-11-07 07:59:58 UTC
*** Bug 121160 has been marked as a duplicate of this bug. ***
Comment 11 Adolfo Jayme Barrientos 2019-01-28 20:12:41 UTC
*** Bug 122882 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2019-11-29 13:27:02 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 13 Justin L 2020-12-14 09:39:02 UTC
Still a fine idea.
Somewhat unnecessary for power users since advanced options has a search now.
Comment 14 Bayram Çiçek 2023-05-11 15:29:29 UTC
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.
Comment 15 Heiko Tietze 2023-05-12 08:25:04 UTC
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)
Comment 16 Andreas Heinisch 2023-05-12 11:24:00 UTC
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
Comment 17 Andreas Heinisch 2023-05-12 11:26:36 UTC
Additional information may be found in the see also section of this bug.
Comment 18 Bayram Çiçek 2023-08-15 13:45:25 UTC
patch https://gerrit.libreoffice.org/c/core/+/152519 is still WIP, but needs test/review and feedback. Thanks!
Comment 19 Commit Notification 2023-08-29 16:02:02 UTC
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.
Comment 20 BogdanB 2023-08-30 17:55:59 UTC
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
Comment 21 Bayram Çiçek 2023-08-30 20:06:08 UTC
(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.
Comment 22 BogdanB 2023-08-30 20:18:57 UTC
Created attachment 189270 [details]
screenshot

No "support" on Accessibility windows. But maybe it is like you said, it's something not visible, but searchable.
Comment 23 Commit Notification 2023-09-04 11:10:40 UTC
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.
Comment 24 Heiko Tietze 2023-09-22 09:07:05 UTC
Some bits might be missing but we can close this ticket as fixed/done. Thanks a lot, Bayram.
Comment 25 Commit Notification 2023-09-25 09:06:14 UTC
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.
Comment 26 Mike Kaganski 2023-10-02 09:52:13 UTC
Needs to be added to release notes, I believe.
Comment 27 Bayram Çiçek 2023-10-06 11:58:03 UTC
(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!
Comment 28 Commit Notification 2023-11-18 06:38:57 UTC
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.
Comment 29 Stéphane Guillou (stragu) 2024-01-26 09:17:35 UTC
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
Comment 30 Moritz Duge (a.k.a. kolAflash) 2024-04-30 16:23:09 UTC
@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)
Comment 31 Bayram Çiçek 2024-04-30 18:48:24 UTC
(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