Bug 120739 - User unfriendly Positioning of the Table (Numbering) Toolbar which Moves the Search Tool Up when a Match is Found Within a Table
Summary: User unfriendly Positioning of the Table (Numbering) Toolbar which Moves the ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Toolbars
  Show dependency treegraph
 
Reported: 2018-10-20 19:54 UTC by Adalbert Hanßen
Modified: 2019-02-19 06:57 UTC (History)
3 users (show)

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


Attachments
search tool pushed up by table tool after a match in a search happens to be within a table. Changing the paragraph's formatting is probable if one blindly clicks again on where the up or down arrow wa (35 bytes, text/plain)
2018-10-20 20:02 UTC, Adalbert Hanßen
Details
description and test case (83 bytes, text/plain)
2018-10-23 13:33 UTC, Adalbert Hanßen
Details
Test case and descriuption what happens with some screenshots taken with two differnt versions of LO Writer. It is an odt-file. (463.73 KB, application/vnd.oasis.opendocument.text)
2018-10-23 21:50 UTC, Adalbert Hanßen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adalbert Hanßen 2018-10-20 19:54:10 UTC
This bug report pertains to LiberOffice Writer, Version: 5.1.6.2, Build-ID: 1:5.1.6~rc2-0ubuntu1~xenial4, CPU-Threads: 4; BS-Version: Linux 4.4; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group. The program runs under Xubuntu 16.04.3 LTS with current linux kernel version 4.4.0-116-generic x86_64 but it might be present in later versions too, which I did not check.

When I do a search I often use the little box which shows up at the bottom left after I pres Ctl-F. I frequently use the up and down arrows next to the search term to go to the next or last match.

However, if a match happens to be inside a table, a numbering tool bar (which is not checked in the list of tool bars) shows up. Unfortunately it goes beneath the search tool and pushes it up by one line.

However, if one searches for search terms, attention is targeted on the document rather than the position of the search tool on the screen. If I click again on the same position on the screen, I click on one of the numbering tools of the table bar which has taken the space previously occupied by the search tool! That’s quite nasty.

I was given the hint to actively position the table (numbering) tool bar vertically to the left border of the LO Writer window. That is a good work around.

But a better solution would be to define the “factory setting” for the table and numbering tool bar such that it never gets into conflict with the search tool bar according to the “factory setting”.

One other nasty thing with the search tool: By default it works in wrap around mode, i.e. when there is no more match in the selected search direction, it rewinds to the beginning of the file and continues search in the old direction if it was a forward search or it jumps to the very end of the file to continue the backward search from there. 

That’s also very clumsy because one has to observe the position of the elevator in the scroll bar. My attention however is on the found match and its surroundings. At least there should be an audible signal if wrap around happens in any search direction. But as I often have to switch off the loudspeaker of my PC in order to not disturb the other people around, it would be better to be able to prevent wrap around all together.
Comment 1 Adalbert Hanßen 2018-10-20 20:02:24 UTC
Created attachment 145864 [details]
search tool pushed up by table tool after a match in a search happens to be within a table. Changing the paragraph's formatting is probable if one blindly clicks again on where the up or down arrow wa
Comment 2 Dieter 2018-10-21 11:36:44 UTC
Thank you for reporting the bug. It seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 3 Adalbert Hanßen 2018-10-21 19:17:59 UTC
the error is also present in 

Version: 6.1.2.1
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: de-DE (de_DE.UTF-8); Calc: group threaded.

The workaround also works in this version.
Comment 4 Xisco Faulí 2018-10-23 11:25:59 UTC
Hello  Adalbert Hanßen,
Would you mind attaching a screenshot or screencast of the problem ?
Thanks in advance
Comment 5 Adalbert Hanßen 2018-10-23 13:33:20 UTC
Created attachment 145933 [details]
description and test case
Comment 6 Adalbert Hanßen 2018-10-23 21:50:50 UTC
Created attachment 145950 [details]
Test case and descriuption what happens with some screenshots taken with two differnt versions of LO Writer. It is an odt-file.
Comment 7 Adalbert Hanßen 2018-10-23 21:54:03 UTC
sorry, somehow the attachment did not go through as meant. Please refer to my next comment and its attachment.
Comment 8 Adalbert Hanßen 2018-10-24 08:44:50 UTC
Sorry again. When I wrote my last comment (2018-10-23 21:54:03 UTC) mentioning my earlier upload of an example (which went wrong, my comment 2018-10-23 13:33:20 UTC), I clicked on "tag" or "reply" assuming that this would let me add a comment to my earlier one and that  everyone would see to which one it belongs. But the comment went to the very bottom (at that moment) and since it had a forward reference (my next comment) there is quite some probability that it gets misunderstood.

This is the attachment 

LoremIpsumTestCase.odt 

which contains the test case plus the screenshots which show what happens.
Comment 9 Dieter 2018-10-24 11:49:45 UTC
I think this bug is related to bug 116553.
Comment 10 Adalbert Hanßen 2018-10-24 12:55:00 UTC
yes, I see it. I did not know about that one.

Still the remedy would be to align the "bullet and numbering toolbar" (which probably is the English name of it) vertically in the default settings. Of course, re-designing the whole UI probably is a hercules job, whereas re-define the default position of the bullet and numbering toolbar to be vertical on the left side and the find toolbar horizontal as close as possible to the lower bottom of the window probably is a small change for someone knowing where to make it. Unfortunately my knowledge does not go to the source code level, but I am sure, there are folks out who can do that within minutes such that this bug will be eliminated in all future versions.
Comment 11 Dieter 2019-02-16 16:32:28 UTC
Tested with 

Version: 6.3.0.0.alpha0+ (x64)
Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

Result: Table Toolbar is now above the Find-Toolbar.

Adalbert, Could you please test with Master (parallel installation by default)(https://dev-builds.libreoffice.org/daily/master/) or with LibreOffice fresh (https://www.libreoffice.org/download/libreoffice-fresh/)? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 12 Adalbert Hanßen 2019-02-18 16:05:48 UTC
Dieter, I tested it with Version: 6.3.0.0.alpha0+
Build ID: aa31976c2e4399a86bc6f70f140972d9ccef6fc0
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-12_16:47:45
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded

I observed that the position of the search forward and search backward buttons remain in their places in this version. This part is significantly improved.

However wrap around still occurs without any notification (I had to work hard to make system-sounds work under my Xubuntu. Now I an quite sure, since now incoming emails produce some plop sound and the login also - time to get rid of at least of the latter again!)

For a silent environment - other than or in addition to proposal above - it would be helpful, to have some optical notification, like a short flickering of LibreOffice's window or something similar. When searching for the occurrence of some search item, the user's focus is on the found instances and he/she should not oversee, that wrapping around the file's end or beginning happens.
Comment 13 Buovjaga 2019-02-18 16:46:57 UTC
(In reply to Adalbert Hanßen from comment #12)
> However wrap around still occurs without any notification (I had to work
> hard to make system-sounds work under my Xubuntu. Now I an quite sure, since
> now incoming emails produce some plop sound and the login also - time to get
> rid of at least of the latter again!)
> 
> For a silent environment - other than or in addition to proposal above - it
> would be helpful, to have some optical notification, like a short flickering
> of LibreOffice's window or something similar. When searching for the
> occurrence of some search item, the user's focus is on the found instances
> and he/she should not oversee, that wrapping around the file's end or
> beginning happens.

If you want, you can create a new report for this. I would advise against flickering as we have had people with sensory sensitivity filing reports asking us to remove all flickering in the UI.
Comment 14 Adalbert Hanßen 2019-02-18 23:06:36 UTC
Buovjaga, you are right and I forgot that: For epileptics, an intense flicker can cause harm. However, reducing the brightness of LO's window background by say 5% (e.g. going from ffffff to f2f2f2 or to ffe0ff (which would be 15% reduction for the green channel alone) for 1/2 second will not affect people suffering from epilepsy.

The acoustic notification seems not to be present in the daily build which I checked.  Shall I open a new bug report for the missing acoustic signal or just only for my modified advice to additionally signal a wrap around optically when a wrap around has happened during search (in any direction)?
Comment 15 Buovjaga 2019-02-19 06:57:58 UTC
(In reply to Adalbert Hanßen from comment #14)
> Buovjaga, you are right and I forgot that: For epileptics, an intense
> flicker can cause harm. However, reducing the brightness of LO's window
> background by say 5% (e.g. going from ffffff to f2f2f2 or to ffe0ff (which
> would be 15% reduction for the green channel alone) for 1/2 second will not
> affect people suffering from epilepsy.
> 
> The acoustic notification seems not to be present in the daily build which I
> checked.  Shall I open a new bug report for the missing acoustic signal or
> just only for my modified advice to additionally signal a wrap around
> optically when a wrap around has happened during search (in any direction)?

You can open a report about wanting a signal, the specifics can be commented on by the design team.