[Libreoffice-ux-advise] [Bug 136920] EDITING: Granularity of start and endpoint for an arrow drawn into a slide

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Oct 15 14:44:14 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=136920

--- Comment #1 from Adalbert Hanßen <adalbert.hanssen at gmx.de> ---
Created attachment 166389
  --> https://bugs.documentfoundation.org/attachment.cgi?id=166389&action=edit
The example used in the bug description

Today I checked this bug again with the most recent version of LibreOffice
Impress, which is currently
Version: 7.1.0.0.alpha0+
Build ID: 231a4e024b85aa0ad06a5632d3f514152babea30
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-GB
TinderBox: Linux-rpm_deb-x86_64 at 86-TDF, Branch:master, Time:
2020-10-14_08:06:21
Calc: threaded

The bug is stil present as one would have expected since no discussion took
part here. Now I give you an example made from a time series computed from
publicly available economic data.

In the slide of the appended graph I want to draw a line or an arrow from the
first to the last data point. In order to do so, I have drawn an arrow but both
terminal points can only be moved in unison using cursor (=arrow) keys.

1.      The end points can not exactly be placed to where I want them by key
movements: Usig this method, they can only placed on coarse grid positions.

2.      Using the cursor keys, both points can only be moved at the same time
by the same amount. Therefore only parallel movement is possible with the arrow
keys. There is nothing to independently move only a terminal point by cursor
keys.

3.      The arrow head does not react on setting it to another size: I want to
increase it by Edit Style>End style. (Side finding).

Click on the arrow in the appended graph such that the end points of the arrow
from the first to the last data point appear as small grey squares and the
mouse pointer becomes an arrow decorated with a small square.

In this mode, moving the mouse while holding the mouse button pressed, the
selected end point moves in discrete steps which are definitely much bigger
than one pixel at the current zoom factor. On the status line, the steps are
indicated as Dx=-0.50, 0.0, 0.50, 1.00, 1.50, .... (N.B.: for consistency, the
designations for the components should both be indicated by lower case letters,
i.e. dx and dy rather than Dx and dy). What is the unit for the Dx and dy
displayed in the status line? If I hold Alt pressed while using cursor keys,
the movement per keystroke seems to be one pixel (which is ok, the  movement in
the graph depends on the set maginification). That’s perfectly ok, but I need
that to manipulate both endpoints independently from each other.

I would propose to let a cursor keystroke actions 

1.      act as presently for consistency (i.e. start in parallel mode),

2.      operate only on the endpoint which has been manipulated last using the
mouse (i.e. continue in end point mode) – until another selection is done by
the mouse, this change appears natural for any user.

3.      return to paralle mode, if one clicks on the middle of the arrow (or
line). This also appears obvious for any user.

Further I would prefer if the single arrow key (i.e. without pressing Alt
simultaneously) would first do what currently Alt+arrow key does. In order to
speed up for larger movements, the transmission ratio should rise from 1 to
let’s say 10 continuously, after repetition has taken place (i.e. to move more
than one step per keystroke after say more than five arrow keystrokes after
another within one second. In order to make smooth transitions when the speed
up starts working, for every 4th arrow keystroke in sequence, a 5th increment
should be performed rising the transmission factor from 1 to 1.25. After
another time interval (e.g. 0.2 seconds) with continuous keystrokes, the
transmission rate should be increased to 1.5, then to 2, 2.5, 3, 4, 5, 6, 7.5,
10. (These speed factors are an approximation of 1.25^n).

One second after the last keystroke of a repetition, the transmission factor
should decay at the same rate as it grew, unless any other arrow key is pressed
while the decay has not come down to 1.0. 

The basic idea of such a variable transmission factor is already known for many
years in the control of a microscope, see for example
https://depatisnet.dpma.de/DepatisNet/depatisnet?action=pdf&docid=DE000003330476A1&xxxfull=1
or
https://depatisnet.dpma.de/DepatisNet/depatisnet?action=pdf&docid=US000004624537A&xxxfull=1
(after twenty years, this invention has become state of the art and there is no
restriction of doing what is revealed there, including transfer of the main
idea of this patent to other subjects than the field of art, for which the
invention originally was made).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libreoffice-ux-advise mailing list