Displayed value in spinner boxes not updated while changing

possibly related to GTK+ issues with value-changed events/interruptibility for spinbuttons?
Bug #168044 “crash adjusting slider when spinbutton has focus (GTK bug?)”
Bug #167781 “opacity in selected style loses focus on kbd value scroll”
Bug #506287 “opacity and blur slider slow and incremental with 0.47 / smooth with 0.46”

reproduced with Inkscape 0.47 r22583 (gtk2 2.18.2) and 0.47+devel r9307 (gtk2 2.18.9) on OS X 10.5.8

Wishlist? Isn't that a bit low for a genuine bug, and an annoying one at that?

I've noticed that in the low values of the line thickness control, for simple shapes, the displayed value *is* continually updated. I think it's related to the redraw speed of the shape that is being affected.

What appears to be happening while I hold down my mouse button is, for each value increase:

1. increase value
2. repaint shape with new value
3. repaint spinner box

But this process is interrupted when the value is increased again (apparently that happens asynchronously), and if it was still redrawing the shape at that point the spinner box is never repainted and the displayed value never updated. When the line thickness is low and the shape simple, my PC can repaint the entire shape before the next value increase, so the displayed value gets updated. If the shape is too complex, or when the line becomes too thick, it takes too long to paint the entire shape before the next value increase. I can actually see this happening: while I'm increasing the line thickness, progressively less and less of the shape gets repainted from top to bottom.

This could be as easy to fix as to make sure the spinner box is repainted first, and *then* the affected shape.

Another fix might be to update the value synchronously, on the event dispatch thread (unless I'm misunderstanding the Gnome / GTK / X11 display event model; I'm only a Java programmer... ;-)).

I'm not a programmer myself - just helping with bug triage. I set it to Wishlist following your initial description as "suboptimal" behavior and because it doesn't prevent to adjust/set the value for the spin box. But I confirm it is a usability issue and also happens when using the scroll wheel to adjust the spinbutton values.

(Possibly related: entries in the undo history for each step even if the spinbox value isn't updated?)

This is not as simple as it may appear. The immediate difference from the paradigm Captain Chaos is used to is that Inkscape is currently a *single* threaded application, and there is not UI event dispatch thread different from a main execution thread.

Alright. How easy would it be to repaint the spinbox before repainting the shape?

It's not.

GTK+ has an event-driven, cross-platform object oriented GUI toolkit. Circumventing the designed flow is not easy, can negatively impact performance and can cause hard to address bugs that might show up only on certain platforms, with certain themes or with certain engines and backends.

duplicate of Bug #184622 “Document property's spinboxes' autorepeat not updating correctly”?

Yes it seems so, from the description in that bug. I note that that bug is two and a half years old, and nothing seems to have been done in all that time, although it seems to have finally been set to "New" three hours ago... (?)