Thomas F. Burdick wrote:
On 2/9/06, Kenny Tilton ktilton@nyc.rr.com wrote:
Peter Herth wrote:
I actually do withdraw windows as soon as they are created to fill them in the background. So that works with all my programs.
Good to know, thx. Yeah, worked for me, too, until I did Something. Programming! :)
This is purely subjective (I haven't written up test cases to find out for sure), but it seems like the fastest way to do things is to withdraw the toplevel, pack from innermost to outermost, then normalize it.
Yep. And if I want to get diabolical I can, instead of sending TK commands as they come up during a propagation, I can save them up and, at the end of any given propagation (as the ultimate step in unfinished-business handling) sort them and write them all to the stream in one blast.
Of course this means Cells needs to accept before, after, around, whatever callbacks to be kicked off after every propagation. Maybe during propagation there is something in the Cells API to register an "after" callback. Possibly one-time or permanent, not that I see a big cost to registering on each propagation.
This does not seem kludgy to me. One thing Cells does is neatly organize the multitudinous state changes arising from some initial state change. OTOH, as I am discovering with Tk, sometimes this well-ordered system has to deal with less well-ordered systems. Tk is a little fragile when it comes to things like:
set .w1 "boo" <create a listbox with textvariable .w1 and items including "boo">
No dice. The order must be reversed or the list does not see the value .w1. ie, The usual problem with imperative vs. declarative.
So a reasonable extension to Cells is a mechanism for talking to external systems sensitive to the ordering of perturbations. But I will wait until Tk proves it needs this or until some other use case comes along.
ken