https://bugs.documentfoundation.org/show_bug.cgi?id=120739
Bug ID: 120739
Summary: User unfriendly Positioning of the Table (Numbering)
Toolbar which Moves the Search Tool Up when a Match is
Found Within a Table
Product: LibreOffice
Version: 5.1.6.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: adalbert.hans...@gmx.de
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.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
