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.
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).
(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.
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.
(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?
(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.
(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...
Created attachment 179564 [details] a flashing widget demo The GtkInspector will "flash" the background of the widget 3 times like this.
(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.
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.
Created attachment 179577 [details] Screencast with patch using VCL=gtk3 Is it supposed to look like this?
Created attachment 179578 [details] Screencast with patch using VCL=kf5 How it looks on Qt.
(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.
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.
(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.
(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?
Created attachment 179585 [details] how gtk dark theme looks for me with patch applied
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)
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.
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.
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.
So, apparently I filed a bug when I noticed the garish animation.