tcl-core

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Koen D. <ko...@re...>]

Jeff Hobbs wrote:
> Koen Danckaert wrote:
>> Joe English wrote:
>>> TIP#306: NO.
>>>
>>> This one does not play nicely with third-party widget sets or with
>>> megawidget packages.  For the former, it places additional 
>>> constraints on widget constructors.  I have no idea how it will
>>> interact with the latter, though I suspect the answer is "not very
>>> well".
>>
>> The TIP describes how mega-widget packages can support the
>> auto-naming scheme. It's really a minor effort.
>>
>> When the TIP was first discussed on this list, Will Duquette (the
>> author of Snit) said he would like to see it happen.
>>
>> Note that the TIP doesn't break compatibility: any application that
>> works today (which obviously doesn't use auto-naming), will continue
>> to work in the future.
> 
> This is so blatantly wrong with a 30 second glance at what's important 
> that anyone who voted yes deserves a right spanking.  This TIP would 
> break BWidgets, and I don't need to look any further.  The TIP blatantly 
> warns on this issue.  Stop the insanity and poor thinking - you break 
> something as basic as that, you will _not_ make a happy community.

Well, the TIP will obviously not be accepted anymore, but the above message is so insulting that I feel obliged to respond.

The TIP does *not* break BWidgets. True, it doesn't support auto-naming for BWidgets, but it does not break anything either (apart from the fact that a single '%' sign could be too fragile - but that seems not to be the problem people are talking about here). It simply does not *apply* to BWidgets. People who do not understand that difference, have the 'poor thinking' at their side. Heck, I wrote the TIP, so I *know* what it warns about.

In hindsight, maybe the TIP should have been called "Auto-naming support for the core widgets", and the section about "Forward compatibility" should have been titled "How mega-widgets can use it too".

But OK, it's too late now to turn the negative sentiments anyway. So let's bury the TIP.

--Koen

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Will D. <wi...@wj...>]

BWidgets creates hidden widgets with "%" in their names, IIRC.

Will

On Nov 27, 2008, at 5:50 AM, Koen Danckaert wrote:

> Jeff Hobbs wrote:
>> Koen Danckaert wrote:
>>> Joe English wrote:
>>>> TIP#306: NO.
>>>>
>>>> This one does not play nicely with third-party widget sets or with
>>>> megawidget packages.  For the former, it places additional
>>>> constraints on widget constructors.  I have no idea how it will
>>>> interact with the latter, though I suspect the answer is "not very
>>>> well".
>>>
>>> The TIP describes how mega-widget packages can support the
>>> auto-naming scheme. It's really a minor effort.
>>>
>>> When the TIP was first discussed on this list, Will Duquette (the
>>> author of Snit) said he would like to see it happen.
>>>
>>> Note that the TIP doesn't break compatibility: any application that
>>> works today (which obviously doesn't use auto-naming), will continue
>>> to work in the future.
>>
>> This is so blatantly wrong with a 30 second glance at what's  
>> important
>> that anyone who voted yes deserves a right spanking.  This TIP would
>> break BWidgets, and I don't need to look any further.  The TIP  
>> blatantly
>> warns on this issue.  Stop the insanity and poor thinking - you break
>> something as basic as that, you will _not_ make a happy community.
>
> Well, the TIP will obviously not be accepted anymore, but the above  
> message is so insulting that I feel obliged to respond.
>
> The TIP does *not* break BWidgets. True, it doesn't support auto- 
> naming for BWidgets, but it does not break anything either (apart  
> from the fact that a single '%' sign could be too fragile - but that  
> seems not to be the problem people are talking about here). It  
> simply does not *apply* to BWidgets. People who do not understand  
> that difference, have the 'poor thinking' at their side. Heck, I  
> wrote the TIP, so I *know* what it warns about.
>
> In hindsight, maybe the TIP should have been called "Auto-naming  
> support for the core widgets", and the section about "Forward  
> compatibility" should have been titled "How mega-widgets can use it  
> too".
>
> But OK, it's too late now to turn the negative sentiments anyway. So  
> let's bury the TIP.
>
> --Koen
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Koen D. <ko...@re...>]

Will Duquette wrote:
> BWidgets create hidden widgets with "%" in their names, IIRC.

No, they use a "#" (not at the last position of their name), just like menus do.

I've been using TIP306 in applications, together with BWidgets, for 1.5 years already... (of course without auto-naming the BWidgets, that simply does not work yet.)

FWIW, I had a quick glance at the BWidget source code. I adapted some of the widgets to be able to use auto-naming, in just 5 minutes. I think it would not take more than 20 minutes to adapt all of them.

I can understand that people prefer a solution that works for all existing widgets at once, but that will be difficult. For example, if TIP180 is done, BWidget will also have to be adapted to make use of it.

--Koen

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Will D. <wi...@wj...>]

On Nov 27, 2008, at 7:30 AM, Koen Danckaert wrote:

> Will Duquette wrote:
>> BWidgets create hidden widgets with "%" in their names, IIRC.
>
> No, they use a "#" (not at the last position of their name), just  
> like menus do.
>
> I've been using TIP306 in applications, together with BWidgets, for  
> 1.5 years already... (of course without auto-naming the BWidgets,  
> that simply does not work yet.)
>
> FWIW, I had a quick glance at the BWidget source code. I adapted  
> some of the widgets to be able to use auto-naming, in just 5  
> minutes. I think it would not take more than 20 minutes to adapt all  
> of them.
>
> I can understand that people prefer a solution that works for all  
> existing widgets at once, but that will be difficult. For example,  
> if TIP180 is done, BWidget will also have to be adapted to make use  
> of it.


OK.  I stand corrected. :-)


------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [TCLCORE] CFV on small high-prio TIPs (#306)

[Joe E. <jen...@fl...>]

Koen Danckaert wrote:

> I can understand that people prefer a solution that works for all existing wi
> dgets at once, but that will be difficult.

	variable % 0
	proc % {} {
	    global %
	    return "autonamed[incr %]"
	}

Then you can write:

	set l [label .f.[%]]

Works for any widget class.


> For example, if TIP180 is done, BWidget will also
> have to be adapted to make use of it.

Why?  That might be a good test case for TIP#180,
but I don't see that it's mandatory.


--Joe English

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

[miguel s. <mig...@gm...>]

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()
> 
> Please send your votes to the tcl-core mailing list by 12:00 GMT next
> Friday (i.e. [clock format 1227873600]). My votes follow:

My votes:

TIP #171: PRESENT
TIP #197: PRESENT
TIP #210: YES
TIP #238: YES
TIP #284: YES
TIP #306: YES
TIP #307: YES
TIP #335: NO [*]
TIP #336: YES
TIP #337: YES
TIP #338: YES


A note on TIP 335: I definitely do not like exposing numLevels, and vote for 
rejection. Joe Mistachkin has stated in this thread that he wanted to change the 
proposal (I guess as a result of our discussions?), and I find the alternative 
very convenient. So my vote should be read as

TIP #335: NO  for the version in the TIP DB
           YES for Joe's less intrusive alternative

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

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

[Kevin K. <ke...@ac...>]

Donal K. Fellows wrote:
>   TIP #171: Change Default <MouseWheel> Bindings Behavior
YES.
The special variety of YES called, "I thought we did that a long
time ago. Silly me, I was using as.tcl all along."

>   TIP #197: Text Widget Persistant Cursor
YES.

>   TIP #210: Add 'tempname' Subcommand to 'file'
YES.

>   TIP #238: Fire Event when Widget Created
YES,  but see below.

>   TIP #284: New 'invoke' and 'namespace invoke' Commands
PRESENT.  As the user who provided the motivating example, I
can't quite bring myself to vote NO, but we seem to be moving
beyond this proposal in a slightly different direction.

>   TIP #306: Auto-Naming Widgets
NO.  Breaks much existing code, for only a minor gain in performance.

>   TIP #307: Make TclTransferResult() Public
YES.  Inoffensive.

>   TIP #335: An API for Detecting Active Interpreters
YES -- in the version that has Tcl_InterpActive; (NO to the one
that queries the stack level.)

>   TIP #336: Supported Access To interp->errorline
YES. With an apology for leaving this piece out of TIP #330.

>   TIP #337: Make TclBackgroundException() Public
YES.  Necessary.

>   TIP #338: Embedder Access to Startup Scripts of *_Main()
YES.  Tk limiting itself to the public API.  How cool is that?

-- 
73 de ke9tv/2, Kevin

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

[Kevin K. <ke...@ac...>]

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.

-- 
73 de ke9tv/2, Kevin

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

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

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

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

[Donal K. F. <don...@ma...>]

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()

Well, at least some of these seem to have passed... :-)

#171: DKF, JN, (DGP), (MS), JH, KBK
#197: DKF, JN, (DGP), (MS), JH, KBK
#210: DKF, JN, JE, !DGP, MS, JH, KBK
#238: DKF, JN, (DGP), MS, !JH, !KBK
#284: DKF, JN, !JE, !DGP, MS, (JH), (KBK)
#306: !DKF, !JN, !JE, (DGP), MS, !JH, !KBK
#307: DKF, JN, JE, DGP, MS, JH, KBK
#335: DKF, JN, JE, DGP, MS, JH, KBK
#336: DKF, JN, JE, DGP, MS, JH, KBK
#337: DKF, JN, JE, DGP, MS, JH, KBK
#338: DKF, JN, JE, DGP, MS, JH, KBK

(To read the above, know that a YES is just the initials, a NO is 
preceded by a ! and a PRESENT is surrounded by parens.)

Passed unanimously with 7/0/0 each:
   #307, #335, #336, #337, #338

Passed with only abstentions, 4/0/2:
   #171, #197

Passed with one against, 6/1/0 (assuming I've represented DGP's vote right):
   #210

Rejected, with recommendation that be left Draft:
   #238 (3/2/1)
   #284 (3/2/2)

Thoroughly rejected, 1/5/1:
   #306 (breaks much code, encourages memory leaks, trivial to replace
        with scripted version)

Thanks everyone for voting!

Donal.