|
From: Jeff H. <je...@ac...> - 2008-11-25 05:29:49
|
Kevin Kenny wrote: > Kevin Kenny wrote: >>> TIP #238: Fire Event when Widget Created >> YES, but see below. > > Jeff Hobbs convinced me to reread the TIP, and I've come > to realise that the specification there is Not Quite Right. > Since we don't have a NOT YET vote, please change mine to > NO. > > It's not as bad as Jeff's message makes out. In particular, > it's useful primarily because there isn't any convenient way > to find out, right now, that a window actually exists; the > closest thing we have at script level is to find out that > it's been made visible, had its geometry requested, or mapped. > (<Visibility>, <Configure> and <Map> respectively). None of > these is quite right. > > Moreover, simply delivering a putative <Create> notification > through the existing binding mechanism ought to work fine. > It is a rare case indeed for which widget creation doesn't > make at least one trip through the event loop before making > the window exist. In any case, the <Create> event is conceptually > coming through the event loop. There is therefore a chance > for the script that defines a window to define its bindtags > before a <Create> has a chance to be delivered. > > I think 238 is salvageable, but not while it's voting. I want to know more about the extended rationale of this tip before it can be determined whether any specification is correct for the problem. Let's go further on the toplevel issue. I use toplevel because it is mentioned in the TIP. One classic example for toplevels is certain display issues like the icon. On Windows, Tk is able to specify the default icon, but on unix you need to specify it per-instance still. The traditional way to do this is override toplevel (and I recommend that instead of this tip). The reason this tip would not supplant the need is due to basing itself off [winfo class] - many toplevels would escape notice. If other examples are more appropriate, I'd really like to see them. Jeff |