Created attachment 163957 [details]
Example file

@Caolán
I'm bit of a pain in the ass about this. IIRC I complained about this also related to the File -> export -> PNG -> PNG dialog

I simply find it strange that's all sorts input methods can 'update' except when entering a value. This from user perspective; there is probably a developer answer to that.

At minimum clicking somewhere inside the dialog (outside input fields) should trigger an update (if nothing else is possible). At least that would work for me (but i'm of course not the general population; so no clue if that would make sense at all)

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.

Lets add Heiko

Would expect on spinner with limits that up/down become disabled. And when you manually enter a value above or below it's adjusted to the maximum/minimum.

*** Bug 138964 has been marked as a duplicate of this bug. ***

(In reply to Caolán McNamara from comment #3)
> 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.
I agree that this can be quite annoying, and like the idea of using a function key for manual update.

(In reply to Heiko Tietze from comment #5)
> Would expect on spinner with limits that up/down become disabled. And when
> you manually enter a value above or below it's adjusted to the
> maximum/minimum.
Heiko, please note that this bug report is specifically about validating, and autocorrecting input during typing. There's no question that the input should be validated and the spinner limits should be updated once the user is done with the change (= the control loses focus).

For editing columns sizes.. which work dynamically this still being annoying.. you get bug 139109.. as you likely not see the remains will be added to columns 1..

My horrific idea is a time based trigger.. say 2 sec since last keypress or so.. But surely not elegant and likely error prone

Only reasoning for bug 138964 and for now more interest in something compared to what's desired.

I would love to be able to click somewhere in the dialog triggering an update. You currently need to specifically click inside one of the edit fields to force an update

I'm talking about Table Properties -> Column tab. But holds also true for PNG export options. 

*Question*
Why is Image 'Compress dialog" Reduce image resolution working as desired/expected?

I don't get an instant update even on scroll or by clicking -/+ buttons. Not sure if this is the intended behaviour.

Version: 7.4.7.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Debian package version: 4:7.4.7-1
Calc: threaded