Re: [TCLCORE] CFV on small high-prio TIPs

[Jeff H. <je...@ac...>]

Donal K. Fellows wrote:
> This is a Call For Votes on the following "small and practical" TIPs
> that I identified from my message earlier this week. (The other ones are
> in the process of being baked more.)
> 
>   TIP #171: Change Default <MouseWheel> Bindings Behavior
>   TIP #197: Text Widget Persistant Cursor
>   TIP #210: Add 'tempname' Subcommand to 'file'
>   TIP #238: Fire Event when Widget Created
>   TIP #284: New 'invoke' and 'namespace invoke' Commands
>   TIP #306: Auto-Naming Widgets
>   TIP #307: Make TclTransferResult() Public
>   TIP #335: An API for Detecting Active Interpreters
>   TIP #336: Supported Access To interp->errorline
>   TIP #337: Make TclBackgroundException() Public
>   TIP #338: Embedder Access to Startup Scripts of *_Main()

Feeling positive ...

TIP #171: YES
TIP #197: YES
TIP #210: YES (voting on TIP design, not implementation)

TIP #307: YES
TIP #335: YES (on latest rev)
TIP #336: YES
TIP #337: YES
TIP #338: YES

Feeling ambivalent ...

TIP #284: PRESENT (is this final ready, or ??)

Feeling negative ...

TIP #238: NO (Fire Event when Widget Created)
TIP #306: NO (Auto-Naming Widgets)

Both of these fail the extensions test.  I recall being no on #238 from 
the beginning because of this.  It isn't even practical to implement 
given the hints, and lacking that should not be supported for vote yet. 
  The rationale isn't really clear enough to answer a few important 
questions ...

* It is implied that these would call different functions:
      toplevel .foo ; # default Toplevel class
      toplevel .foo -class MyToplevel
Is that expected?

Tk_MakeWindowExist is certainly not where you would implement this. 
That is sometimes called just before a widget is destroyed, and 
sometimes delayed until first Map (in which case, use <Map>).  If this 
is intended for _all_ Tk widgets, how do extensions tie in?  What Tk 
really needs is improved use of the classProcs and extensions to that, 
but even that isn't fully propagated.

I think #238 is still best served by subclassing (choose your favorite 
subclassing method).  I think again TIP #180 should solve this in part 
(in snidget snit::widgetadaptor style).

As for #306, I do like the idea of auto-naming, but breaking compat with 
existing widget sets (which it clearly states can happen) is bad bad 
voodoo in my book.

Jeff