Hi,
I've been looking into the cause of this bug:
https://bugs.launchpad.net/inkscape/+bug/561503
As far as I can tell, the bug is exposed when the spinboxes are initialized in CanvasXYGrid::newSpecificWidget(). (display/canvas-grid.cpp).
Starting on line 732 or so, there is a series of calls to setValue() on the origin x/y and the spacing x/y RegisteredScalarUnit instances. These calls to setValue() end up setting the setProgrammatically flag to "true", which is supposed to be immediately cleared in the on_value_changed callback, *BUT* for the origin boxes, the on_value_changed callback is never called, and the flag never gets cleared. The initial value of the spinboxes is "0", and we're setting them to their default of "0", so my guess is that GTK doesn't bother to call on_value_changed in the case that the value hasn't actually changed.
So then when the user changes the widget for the first time, it has no effect because the first call to the on_value_changed callback only clears setProgrammatically instead of actually doing anything.
I wasn't totally sure about the best way to fix this. It's not clear to me why Scalar::setValue() doesn't just do a "setProgrammatically = false" after the call to the widget's set_value(). It seems like it would be simpler and more robust than clearing it in each callback.
However, I assumed that there was some sort of reason I couldn't see for leaving it up to the callbacks to reset it, so my (attached) fix is to make Scalar::setValue() not do anything at all if the new value is the same as the old value. This fixes the issue at hand, however, as su-v pointed out to me on the IRC channel, it seems odd that this isn't a more widespread problem. What about all the other spinboxes that default to zero? I'm not familiar enough with the codebase to know why the bug was only exercised in that particular area.
As an aside, what do you guys use to debug Inkscape? I tried just using gdb, but I found that setting breakpoints changed the behavior of the program (!), so I ended up just printing to stdout with debugging info, which is quite tedious.
Cheers,
Jason