Bug 150810 - Make the Search Commands dialog easier to understand
Summary: Make the Search Commands dialog easier to understand
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 target:7.4.2
Keywords:
: 151226 (view as bug list)
Depends on:
Blocks: HUD
  Show dependency treegraph
 
Reported: 2022-09-05 21:09 UTC by Eyal Rozenberg
Modified: 2022-09-29 12:50 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (3.88 KB, image/png)
2022-09-06 06:58 UTC, Heiko Tietze
Details
Screenshot with GTK3 (118.19 KB, image/png)
2022-09-06 18:24 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-09-05 21:09:14 UTC
When a user opens the Search Commands dialog, they get two white regions in a pop-up dialog, with no content, no dialog title, no anything.

This is confusing, especially for unexperienced users. The situation should be ameliorated. My concrete suggestions (which aren't the only possible improvements) would be:

1. Have a faint gray text in the top textbox indicating what one is to type there, e.g. "Action Name..." or "(Action Name)" or "Type action name". It disappears when the user starts typing
2. Add a pop-up dialog title bar, or labels, or both, clarifying what the dialog is about.
3. Fill the result pane already when the dialog comes up, with "search" results for all commands - no filter.
Comment 1 V Stuart Foote 2022-09-06 01:53:45 UTC
+1 to provide a little decoration to the dialog.
Comment 2 Heiko Tietze 2022-09-06 06:58:46 UTC
Created attachment 182244 [details]
Screenshot

The input field shows the tip "Search command". Doesn't it work for you?

Version: 7.4.0.3 / LibreOffice Community
Build ID: 40(Build:3)
CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (en_US.UTF-8); UI: en-US
7.4.0-3
Calc: threaded
Comment 3 Tomaz Vajngerl 2022-09-06 11:42:08 UTC
> The input field shows the tip "Search command". Doesn't it work for you?

Not in gtk3, where the text is not shown when the edit box is in focus, and it needs to be in focus so you can start writing right away...
Comment 4 Eyal Rozenberg 2022-09-06 18:24:37 UTC
Created attachment 182269 [details]
Screenshot with GTK3

This is what the dialog looks like for me.
Comment 5 QA Administrators 2022-09-07 03:59:30 UTC Comment hidden (obsolete)
Comment 6 Heiko Tietze 2022-09-07 07:21:02 UTC
Caolan, do we follow the Gnome standards with hiding the tip immediately when it receives the focus? Qt shows it until something is inserted. If so, any idea how to solve it - except simulating the behavior.
Comment 7 Caolán McNamara 2022-09-07 10:33:45 UTC
This thing is a "placeholder" and the focus issue seems to be a long standing bugbear: https://gitlab.gnome.org/GNOME/gtk/-/issues/378

Right now in gtk4 I see that the placeholder text is shown with focus where gtk3 doesn't. I think I have some ideas about getting this to appear to work in gtk3 anyway.
Comment 8 Heiko Tietze 2022-09-07 11:17:29 UTC
I wonder how it look under Windows and macOS.
Comment 9 Commit Notification 2022-09-07 14:07:00 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9220716bed8ff4337453f06788233aa73463d63b

tdf#150810 get visible placeholder text in GtkEntry with focus

It will be available in 7.5.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 10 Caolán McNamara 2022-09-07 14:09:00 UTC
I'd expect the mac and win cases to be the same as the kf5/gen case.

The above makes it appear the same for gtk3 as far as I can, though subverts the focus drops placeholder intention of that toolkit. So done in trunk IIUC, I have a backport to 7-4 in gerrit.
Comment 11 V Stuart Foote 2022-09-07 14:52:27 UTC
(In reply to Heiko Tietze from comment #8)
> I wonder how it look under Windows and macOS.

I see the placeholder "Search command" labeling in both Light mode and in Dark mode on Windows 10.
Comment 12 Eyal Rozenberg 2022-09-07 17:29:23 UTC
I certainly appreciate the patch, but that's just one improvement. I've suggested three, and there may be other ideas. So, there needs to be a decision whether the other two are relevant or not, and if not, perhaps something else in addition.
Comment 13 Heiko Tietze 2022-09-08 07:03:59 UTC
(In reply to Eyal Rozenberg from comment #0)
> 2. Add a pop-up dialog title bar, or labels, or both, clarifying what the
> dialog is about.

Would be an improvement design-wise but clutters the UI for no good reason. You start the feature manually and you get now a tip what it does. Sufficient IMO.

> 3. Fill the result pane already when the dialog comes up, with "search"
> results for all commands - no filter.

Pre-filling the results makes not much sense. Perhaps we can hide/collapse until the first results. Tomaz, what do you think?


Keep also in mind that one wish is to have place the input field on the notebookbar.
Comment 14 Commit Notification 2022-09-09 14:41:48 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/1cba31a159fb1ed4795adeea968dc915b95d64a5

tdf#150810 get visible placeholder text in GtkEntry with focus

It will be available in 7.4.2.

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 15 Heiko Tietze 2022-09-29 12:47:06 UTC
*** Bug 151226 has been marked as a duplicate of this bug. ***