From: Brian G. <bri...@ea...> - 2015-11-19 16:13:22
|
On Nov 19, 2015, at 7:04 AM, Jan Nijtmans <jan...@gm...> wrote: > > 2015-11-18 21:30 GMT+01:00 Francois Vogel: >> Thanks to Brian and Koen for providing their thoughts regarding the >> two proposals we currently have. >> >> The thing is: IIUC they do not agree :-) >> >> How do we resolve this so that, again, we can move on? > > Well can't we have both? I'm fine with this. >> I do not see clearly what our next move is. Let's not keep this stuff >> stuck, we all have it fresh in our minds now, we should make the final >> effort to decide what's the solution. I will then happily take care of >> implementation and docs and whatnot. > > I would like to add the 'callback' implementation to the TIP > branch, and then open the branch for experimenting. Questions > to be asked: > - How much is the burden for the events to be fired if they > are not 'consumed' I doubt it's heavy since several widgets have several virtual events that, presumably, are firing all the time with "nobody listening." (http://www.tcl.tk/man/tcl8.6/TkCmd/event.htm#M41) I also think the count parameter for the event is unnecessary. The event should fire twice, once when the view is out of sync, and again when in sync with the data. > - If we want to generalize it for other than text widgets, > is the name 'yupdate' as command line still adequate? I've never really cared for 'yupdate', but didn't have an alternative to suggest, but now I do. I think 'sync' makes the most sense to me. The idea is that a widget can have a period of time where the internal data model is not in sync with the view. The 'sync' method would force the view to be in sync with the data. The matching event would be <<WidgetViewSync>> with %d being true (1) or false (0). I would suggest that any widget operation that modifies the data model would not trigger a sync event unless the view would not be in sync after the command returns. -Brian |