Tk Source Code

I use the following routine to move a scale widget in my tests.
This no longer works in 8.6.10.

proc moveScale { w val } {
  lassign [$w coords] xo yo
  lassign [$w coords $val] x y
  focus $w
  update
  event generate $w <Motion> -warp 1 -x $xo -y $yo
  update
  event generate $w <ButtonPress-1> -x $xo -y $yo
  update
  event generate $w <Motion> -warp 1 -x $x -y $y
  update
  event generate $w <ButtonRelease-1> -x $x -y $y
  update
  doSleep 200 ; # give time for the change to take effect
}

Well, I agree with the reasonings here (by @marc_culler and @fvogel). We should just make sure that this _potential_incompatibility_ will be described well in the 8.6.10 changelog, as a behaviour which always has been wrong in the past!

Also, I don't see how restoring indeterminacy can provide true backward compatibility. Since the behavior of UpdateButtonEventState depended on the inherited value of the display's button state vector, which was completely arbitrary and not knowable in advance, it seems to me that any event generation code which behaved in a consistent way in the past was doing so by accident.

My preference would be to not restore UpdateButtonEventState and to add a warning in the changes file as Brad recommends.

The situation is that the event generate command allows generating sequences of events which could never be produced by an actual device. UpdateButtonEventState silently changes generated events in an unreliable and necessarily imperfect attempt to replace such an event sequence with one which is physically possible.

I just read the manual page for the event command. I saw nothing indicating that the state of a generated event might get changed in some unpredictable way if it appears to be part of a physically impossible event sequence. So I think that there is nothing in the documentation which suggests that Brad's code would behave the way it used to behave, and in fact the documentation does suggest that it will behave in the way that it now does. I think the current behavior is preferable to the previous one.

The problem with restoration of UpdateButtonEventState() is that it would resurrect bug [c1c842ef77].

I would be slightly reluctant to see this happen. I believe the test suite before TIP #532 (new tkBind.c) didn't reveal issue [c1c842ef77] but it was there. The test suite [84fbb57ab3e86886|got augmented] by TIP #532, and I think the added tests revealed the bug.

Restoring UpdateButtonEventState() in 8.6 for the sake of backwards compatibility would be possible, but then we should modify the test suite (in 8.6 only) to avoid triggering test suite errors that we would see for years in our logs.

event generate of a button motion may be rare enough so that it just needs to documented as a breaking change in the change log.

Well, the 3th "event generate" should have been <B1-Motion> in stead of <Motion>. Tk always corrected the button-state between ButtonPress and ButtonRelease events, but doesn't anymore since the "crazy function UpdateButtonEventState" was removed ;-) [3b3c3b02]

Actually, I don't think that Tk should have done those state corrections but it - indeed - means that this kind of code breaks because of that change.

@fvogel @culler: Maybe we should restore UpdateButtonEventState() in Tk 8.6 (or a subset of this function), so people can get accustomed to the new (more correct) behavior in Tk 8.7