[Libreoffice-bugs] [Bug 135454] UI: Other fields aren't updated at manual input (you have to jump to different field)

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #3 from Caolán McNamara <caolanm at redhat.com> ---
On up/down/scroll the change is simple and the value is changed by that event.
During manual typing to edit the value does not change until there is some
trigger to indicate that the edit is complete. Losing focus is the usual
trigger that indicates the edit is done and the value is updated from the input
(and the output formatted from the value). And then value-change is broadcast
and other widgets whose values depends on the spinbutton update based on the
new value.

If you update the value on any edit change, then you have two additional
problems. You shouldn't format the number and replace the text currently being
edited as it would change the text of the widget while you are typing. The main
problem is that as you type other widgets that depend on the value of the
widget you are editing will update immediately to match their relationship to
the value. Tab into your widget, press 123, the value goes to 0 as its
overwritten, then to 1, then to 12, then to 123. You get radical noisy jumps in
the dependent widgets as they clamp to their mins and maxes as those
"intermediate" values arrive.

As a real world example, if you look at LibreOffice 4.1, calc, format cells,
alignment and the degrees spin button, you cannot delete the "0" there with
backspace, it reappears immediately, if you use the up button to take it to
e.g. 20, then try to delete with backspace the 20 to replace it with something
else it will turn into 2 with the cursor before 2. If you decide to just type
40 before that 2, planning to delete the 2 afterwards then the 402 is clamped
and turned into 359 before you get a chance to turn 402 into 40. So IMO an
update immediately model is fraught with difficulties too, but one where the
update happens on losing focus is simple, and is the built-in way that a
GtkSpinButton works out of the box.

Though, adding a key binding to update a spinbutton from the users input
without moving focus elsewhere would be fairly easy to do if some such binding
like F9 or shift+return was seen as acceptable. A bare Enter/Return is already
taken typically to close the dialog as if OK was pressed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200805/b7969216/attachment.htm>