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.
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
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.
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.
Hello Adalbert Hanßen, Would you mind attaching a screenshot or screencast of the problem ? Thanks in advance
Created attachment 145933 [details] description and test case
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.
sorry, somehow the attachment did not go through as meant. Please refer to my next comment and its attachment.
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.
I think this bug is related to bug 116553.
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.
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.
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.
(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.
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)?
(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.