[ltk-user] Socket problem....

[Kenny Tilton]

Thomas F. Burdick wrote:

>On 2/9/06, Kenny Tilton <ktilton at 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