Bug 148349 - Use attention-attracting cue when pressing Ctrl+F while in the find bar
Summary: Use attention-attracting cue when pressing Ctrl+F while in the find bar
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks: Find-Toolbar
  Show dependency treegraph
 
Reported: 2022-04-04 08:22 UTC by Eyal Rozenberg
Modified: 2022-04-17 15:36 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
a flashing widget demo (690.13 KB, video/webm)
2022-04-14 15:05 UTC, Caolán McNamara
Details
Screencast with patch using VCL=gtk3 (135.60 KB, image/gif)
2022-04-15 07:40 UTC, Heiko Tietze
Details
Screencast with patch using VCL=kf5 (184.69 KB, image/gif)
2022-04-15 07:41 UTC, Heiko Tietze
Details
Screencast without patch using VCL=gtk3, light theme (171.56 KB, video/mp4)
2022-04-15 08:20 UTC, Eyal Rozenberg
Details
how gtk dark theme looks for me with patch applied (78.04 KB, video/webm)
2022-04-15 13:02 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-04-04 08:22:33 UTC
Sometimes, on a tall screen, the user may forget that the find bar is currently active, and may press Ctrl+F again, expecting something to happen (e.g. a dialog box like in other apps). At least - it happens to this user...

Anyway, in that situation, it would be nice if there was some cue to attract the user's attention to the find bar: Some kind of visual "ding", so to speak - a color change to-and-back, a disappearance and reappearance, etc.
Comment 1 Heiko Tietze 2022-04-04 09:26:30 UTC
Color animations are fancy modern design details- and rather not appropriate to our old-school application. But in fact we could do something beyond moving the caret into the find dropdown. Either expand the dropdown to show the former searches or change the color to indicate the possible input (on my dark theme I always have some very dark grey and could imagine white instead).
Comment 2 Heiko Tietze 2022-04-04 09:26:31 UTC Comment hidden (obsolete)
Comment 3 Eyal Rozenberg 2022-04-04 10:23:23 UTC
(In reply to Heiko Tietze from comment #1)
> Color animations are fancy modern design details- and rather not appropriate
> to our old-school application.

I didn't mean an animation per se, but something like how when you click a textbox, you get a frame around it; so maybe draw that, then undraw it or vice-versa. Or remove the cursor, then bring it back. Or unfocus the textbox, then re-focus it.

But frankly, I don't mind what specifically you choose to do. Expanding the dropdown is fine, or anything else.
Comment 4 Heiko Tietze 2022-04-14 12:16:24 UTC
Topic was on the agenda for the design meeting but didn't receive further input. 

Could imagine some default similar to set_message_type(). Caolan, any idea?

If not let's change the border color to the highlight color and fade out within 500 ms.
Comment 5 Eyal Rozenberg 2022-04-14 13:51:13 UTC
(In reply to Heiko Tietze from comment #4)
> If not let's change the border color to the highlight color and fade out
> within 500 ms.

Isn't the border color already the highlight color in this case? i.e. my find bar textbox border is blue. Perhaps un-highlight it, then re-highlight it? i.e. flash it?
Comment 6 Heiko Tietze 2022-04-14 14:00:52 UTC
(In reply to Eyal Rozenberg from comment #5)
> Isn't the border color already the highlight color in this case?

You are right, when the control receives the focus its border become blue, in my case. Given that this is a system behavior I wonder if we really want to introduce a more obtrusive behavior.
Comment 7 Eyal Rozenberg 2022-04-14 14:13:10 UTC
(In reply to Heiko Tietze from comment #6)
> (In reply to Eyal Rozenberg from comment #5)
> > Isn't the border color already the highlight color in this case?
> 
> You are right, when the control receives the focus its border become blue,
> in my case. Given that this is a system behavior I wonder if we really want
> to introduce a more obtrusive behavior.

Yes we do, because this is _not_ obtrusive. Once the highlight is on, it's a static thing. Pressing Ctrl-F does nothing, hence this bug report...
Comment 8 Caolán McNamara 2022-04-14 15:05:59 UTC
Created attachment 179564 [details]
a flashing widget demo

The GtkInspector will "flash" the background of the widget 3 times like this.
Comment 9 Eyal Rozenberg 2022-04-14 16:38:11 UTC
(In reply to Caolán McNamara from comment #8)
> Created attachment 179564 [details]
> a flashing widget demo
> 
> The GtkInspector will "flash" the background of the widget 3 times like this.

Sure. I would think just once is enough (since if you're Ctrl+F'ing, you'll probably notice), but 3 times is ok too.
Comment 10 Caolán McNamara 2022-04-14 19:55:36 UTC
well, https://gerrit.libreoffice.org/c/core/+/133030 for the flashing background idea (one flash). It's probably worth noting that ctrl+f has another special thing from bug 82502 to select all the text inside the findbar.
Comment 11 Heiko Tietze 2022-04-15 07:40:37 UTC
Created attachment 179577 [details]
Screencast with patch using VCL=gtk3

Is it supposed to look like this?
Comment 12 Heiko Tietze 2022-04-15 07:41:14 UTC
Created attachment 179578 [details]
Screencast with patch using VCL=kf5

How it looks on Qt.
Comment 13 Eyal Rozenberg 2022-04-15 08:19:08 UTC
(In reply to Heiko Tietze from comment #11)
> Is it supposed to look like this?

With the dark theme, the surrounding rectangle is almost unnoticeable. With the light theme it's somewhat better. Will add attachment.
Comment 14 Eyal Rozenberg 2022-04-15 08:20:56 UTC
Created attachment 179579 [details]
Screencast without patch using VCL=gtk3, light theme

Screencast illustrating how focusing and un-focusing the textbox on the find bar is much more noticeable in light theme than in dark theme.

I wonder whether this is GTK's "fault" or ours.
Comment 15 Telesto 2022-04-15 08:50:56 UTC
(In reply to Eyal Rozenberg from comment #0)
> Sometimes, on a tall screen, the user may forget that the find bar is
> currently active, and may press Ctrl+F again, expecting something to happen
> (e.g. a dialog box like in other apps). At least - it happens to this user...

Well I agree that Find bar doesn't pop out (in contrary to find and replace). I'm having the same experience

Although it's ruled out already, but I was kind of thinking of making the background of the find input field subtitle 'yellow' on pressing CTRL+F (and white again after user input, only becoming yellow again after pressing CTRL+F.

Those 'border effects' are not really fitting into the Windows UI (but well not to familiar with Win10 and 11)

----
Regarding to comment 1: Special effects are already there: press CTRL+F in empty document and type Hello + Enter. "Hello" will turn red. 

[Although I find the Firefox solution better, but turning the background red, and input white]. However I'm not visual impaired specialist. 

It would make yellow background more consistent.
Comment 16 Eyal Rozenberg 2022-04-15 09:17:54 UTC
(In reply to Telesto from comment #15)
> Those 'border effects' are not really fitting into the Windows UI (but well
> not to familiar with Win10 and 11)

But aren't the border effects something that GTK3 does for us? That, in Windows, will be replaced by some other effect - like in Qt you get the background color change?
Comment 17 Caolán McNamara 2022-04-15 13:02:12 UTC
Created attachment 179585 [details]
how gtk dark theme looks for me with patch applied
Comment 18 Caolán McNamara 2022-04-15 13:38:10 UTC
comment #11 recording wrt gtk and dark theme with the "flash" applied looks very underwhelming vs what I see (as in comment #17) which looks reasonable.

FWIW the existing border mentioned in comment #13 and #14 belongs to gtk and isn't under our control.

wrt #15 Its hard to use explicit colors but otherwise follow the system theme without getting a conflict for some user or other eventually :-( It's nice when there is some suitable theme element to derive it from to avoid the whole issue. Nevertheless... Looking into it a little I see that for the "warning mode" and the gen widgets we have a different set of colors used for an entry vs a combobox and the entry warning colors are as you preferred "background red, and input white" so I'll unify the handling of comboboxes and entry warnings modes together. (FWIW for gtk the warning mode is shown with an icon indicator and not via colors)
Comment 19 Commit Notification 2022-04-15 18:45:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d1da1c59d196b7f6037b7e0820b81fc527d56a4c

tdf#148349 add a way to call the user's attention to a widget

It will be available in 7.4.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 Caolán McNamara 2022-04-15 18:50:51 UTC
Tried lengthening the "blink" and making it more opaque to see if that improves things vs comment #11. In any case a call_attention_to() that does "something" transitory to attract the attention of the user exists now.
Comment 21 Commit Notification 2022-04-17 15:36:10 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/689d1f5dd3dc12d9f85ba98702a66c7af20849dc

Related: tdf#148349 gtk[3|4] use a css effect to draw attention to the widget

It will be available in 7.4.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.