From: Donal K. F. <don...@ma...> - 2003-12-11 11:41:50
|
I've been looking over the TIPs that are currently in Draft and Deferred state and which are fairly old with an eye to what we can do to be more pro-active as a Team. This isn't the first time I've done this, but previously it has always been on the Tcler's Chat and so has been merely transient. The aim of this message is to raise awareness of proposals pending and try to encourage people to move on with getting things into the core (or rejected/withdrawn). I suppose you can see this as me trying to act as a Serjeant-at-Arms and get people to pull their weight, but I'm just trying to make sure that the TCT appears to be pro-active to the outside world (not an impression we've really been giving recently...) Nothing submitted in the past three months (i.e. since the start of October) or aimed at Tcl/Tk 9.0 is listed here (except for one which feels mis-targetted to me.) If any of those need action, they should be either recent enough for people to remember for themselves or are being put off for good reasons. Draft (34 TIPs): * *#38 "Default Bindtags"* - Would someone with experience of megawidget construction please comment on this TIP? * *#39 "-component Option to Tk Widgets"* - Would someone with experience of megawidget construction please comment on this TIP? * *#42 "-clientdata Option to Tk Widgets"* - Would someone with experience of megawidget construction please comment on this TIP? * *#46 "Canvas Item Overlap Behaviour Consistency"* - I believe that the current behaviour (that you can have sensitive invisible polygons) is more useful. * *#51 "Native Mac Menubutton"* - Would a Mac Tcler like to comment on whether this has been obsoleted by the move to MacOSX? * *#52 "Hierarchical Namespace Lookup"* - I think this is too rigid. * *#57 "Multi-Assign"* - If we make the syntax exactly that of TclX's [lassign], I'd be happy to see this feature in the core. In fact, I might even take on chasing this one down myself. (There are several possible syntaxes, but I see absolutely no reason to do anything other than the TclX style, especially as it is probably fairly easy to compile and also has nice properties relating to the result of the command.) * *#60 "EXTERN Macro Modifications"* - Does the Borland compiler still behave gratuitously differently to the VC compiler? What about other Win compilers? Any relevance for non-Win compilers? * *#67 "Subclassing tk_get*File on Unix"* - I'm not happy with this, but I can't quite put my finger on what's wrong. * *#70 "Relational Switch"* - I believe this properly belongs in the domain of tcllib or some other extension. * *#71 "Bitmap Improvements"* - While this is valuable in as far as it goes, I suspect that we should be doing this with bitmap images instead, especially as arrows are not likely to be useful for cursors or stipples. (Ideally we'd allow bitmap images to be used anywhere where bitmaps are, but that's much harder to do.) * *#86 "Source-file Line Number Info for Procs"* - This would be cool IMHO. I'm not sure if the technical challenges were ever solved though. * *#89 "Try/Catch"* - Why is this one languishing? * *#97 "Moving Vertices"* - I think this would be a nice small useful enhancement to the canvas. * *#106 "Encoding and [dde]"* - Is this still relevant with the other work that has been done on the dde package? * *#117 "Object Type Introspection"* - This breaks the Tcl semantic model, but since it is only a "for debugging" proposal that's not necessarily a reason for an out-of-hand rejection. * *#119 "Angled Canvas Text"* - I worry about portability with this, but it would be nice to have. * *#122 "Pervasive tcl_wordchars Use"* - AIUI, someone's got hold of the wrong end of the stick with this one. :^) * *#125 "wm toplevel"* - Enables many cool things (tear-off-able toolbars, MDI) but I'm not sure about whether it can be made to work across all platforms. * *#128 "Custom Memory Allocator"* - I've no reason to object to this, but no real opinion either. Any comments? * *#129 "New [binary] Format Codes"* - Things are happening with this TIP. More on this list probably in the new year. * *#132 "Floating-Point Conversion Improvement"* - Apparently this is a real bear to implement. :^( * *#133 "Extending [expr] Operators"* - Taken in a narrow sense, a new 'in' operator for list (a.k.a. set) membership is no problem. In a wider sense, having the ability to install new operators using scripts would be nice, but is much more complex to actually do. I'm not 100% sure which the TIP is actually referring to. * *#134 "Subsystem Per-Thread Data Interfaces"* - I don't like this. IMHO subsystems should keep themselves to themselves, only exposing their internal state through a well-defined per-subsystem API. * *#140 "Tracing Namespace Mods"* - I might defer or withdraw this TIP. * *#141 "Multiple Initial Files to tk_getOpenFile"* - IIRC we're getting closer to agreement on how this should actually happen, yes? Once we have that agreement, I think we can move forward with the TIP. * *#142 "Command Lookup Search Path"* - Tries to attack the same area as #52, but actually manages to be a worse suggestion. I'd much rather we had a third TIP that supercedes both of these and which does something more sophisticated that is controllable on a per-namespace basis. * *#143 "Resource Limiting Framework"* - I need to do some implementation work on this one. Which means I need to find a few days worth of free time... * *#145 "Enhanced Tk Font Handing"* - Could someone assess this TIP please? I don't grok the Win internals... * *#149 "enabled==normal in -state"* - I think this is a really bad idea, but then I also know some of what Joe English has been up to with the style engine, and that work is completely incompatible with this TIP. * *#152 "-detail Option to tk_messageBox"* - I'd love to see this (which would be trivial on Unix.) All we need is a plan for what to do on Windows where things are much less flexible than everywhere else. * *#153 "winfo tophierarchy"* - I don't understand this TIP. :^) * *#154 "Named Colors"* - This would be cool and very helpful in making Tk look more modern. * *#158 "Distinguishable Enter Keys"* - I'm going to leave this one up to KBK (who I know has been busy recently) but the justification feels fine to me and it is a fairly recent TIP too so I'm not too worried. Deferred (6 TIPs): * *#20 "Locale-Aware CType Functions"* - Is this still relevant, Jeff? * *#50 "Bundle [incr Tcl]"* - Requires effort from itcl people to adapt to the core build mechanism and set up the rest of the process (e.g. maintainer areas and assignments). I don't feel like helping. * *#61 "Runtime Switching of [send] Security"* - Do you want to revisit this, Jeff? * *#64 "Win Font Handling Improvements"* - Is this superceded by #145? * *#83 "Tcl_EvalChannel/Tcl_EvalUrl"* - These are trivial operations (EvalChannel obviously so, EvalUrl when you have the TclVFS extension.) * *#105 "[switch] Prefix Matching Style"* - I'm still not sure if this is one of my good ideas or one of my bad ideas. Other: * *#110 "Tristate check/radiobuttons"* - Why is this targetted at Tk 9.0? Can't we have this for 8.5? Donal. |
From: <da...@de...> - 2003-12-11 12:24:52
|
"Donal K. Fellows" <don...@ma...> writes: > * *#141 "Multiple Initial Files to tk_getOpenFile"* - IIRC we're > getting closer to agreement on how this should actually happen, > yes? Once we have that agreement, I think we can move forward > with the TIP. From the email I have read about it, it seems like it's really just a judgement call/vote on whether the potential incompatibility is worth it or not. I haven't seen any alternative suggestions. If there are any, I guess I could devote some time to implementing them. -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/ |
From: Pascal S. <pa...@sc...> - 2003-12-11 13:53:22
|
Donal K. Fellows wrote: > * *#133 "Extending [expr] Operators"* - Taken in a narrow sense, a > new 'in' operator for list (a.k.a. set) membership is no problem. That was Richard's idea, and I would still like it. > In a wider sense, having the ability to install new operators > using scripts would be nice, but is much more complex to actually > do. I'm not 100% sure which the TIP is actually referring to. That would be my fault. Apart from what is in the TIP, I think I initially made that remark thinking of using it to do GMP/arbitrary precision math operators. I'm still interested in that, but have other things to do just now. I think having the 'in' and possibly the 'empty' operator mentioned later on in the TIP is more important, although this would introduce a feature that can help backward portability (thinking of tcllib) in the future. - Pascal. -- --- More about me http://pascal.scheffers.net PGP key: 0xA089 B477 on the keyservers |
From: antirez <an...@in...> - 2003-12-11 14:13:14
|
On Thu, Dec 11, 2003 at 02:54:01PM +0100, Pascal Scheffers wrote: > I think having the 'in' and possibly the 'empty' operator mentioned > later on in the TIP is more important, although this would introduce a > feature that can help backward portability (thinking of tcllib) in the > future. It's not integrated in expr... but maybe this may help: http://hping.org/tclsbignum If needed I may change the licence to BSD. Regards, Salvatore -- Salvatore Sanfilippo <antirez at invece dot org> "However, there is a tension between making the language simpler and making the organization of a system manifest. As the variety of costructs decreases, so does the variety of linguistic clues of a system's structure." (Ungar and Smith) |
From: Brian G. <bgr...@mo...> - 2003-12-11 14:56:55
|
> * *#125 "wm toplevel"* - Enables many cool things (tear-off-able > toolbars, MDI) but I'm not sure about whether it can be made to > work across all platforms. I would like to open discussion on this to see if there are any more issues and then CFV in say 3-4 weeks. As for the MAC platform, I am planning on looking hard and this implementation in the next week, but even failing an attempt to implement this for the MAC, I believe it's still a reasonable addition because a) it's useful for implementing common features found Win* and *nix and b) these same features are not found on MAC. > > > Other: > > * *#110 "Tristate check/radiobuttons"* - Why is this targetted at Tk > 9.0? Can't we have this for 8.5? You are right, I just need to get my butt in gear and implement this. Again, I'd like to call for discussion then call for vote. > > > Donal. Thanks Donal for doing this! -Brian > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > -- ------------------------------------------------------------- -- Model Technology Inc. -- -- 8005 SW Boeckman Road 503.685.7000 tel -- -- Wilsonville, OR 97070 USA 503.685.0921 fax -- ------------------------------------------------------------- -- Technical support ............ mailto:su...@mo... -- -- Sales and marketing info ....... mailto:sa...@mo... -- -- Licensing .................... mailto:li...@mo... -- -- Home Page ........................ http://www.model.com -- -- AIM ........................................ bgriffin42 -- ------------------------------------------------------------- |
From: Jim I. <ji...@ap...> - 2003-12-11 19:04:27
|
Brian, On Dec 11, 2003, at 6:56 AM, Brian Griffin wrote: > >> * *#125 "wm toplevel"* - Enables many cool things (tear-off-able >> toolbars, MDI) but I'm not sure about whether it can be made to >> work across all platforms. > > I would like to open discussion on this to see if there are any more > issues and then CFV in say 3-4 weeks. As for the MAC platform, I am > planning on looking hard and this implementation in the next week, but > even failing an attempt to implement this for the MAC, I believe it's > still a reasonable addition because a) it's useful for implementing > common features found Win* and *nix and b) these same features are not > found on MAC. > Some of the Tk widgets are backed by Aqua Toolbox controls. These controls are tied to the Aqua Window in which they are drawn. To move controls from one Aqua window to another would require destroying the Aqua control, and then re-creating it in the new Aqua window you create for the frame. There isn't currently a convenient way to do this, but it shouldn't be all that hard to do. We don't store any state in the Aqua controls, and the Aqua Tk widgets are all designed to lazily create the Aqua controls when the widgets are first mapped. So you should just have to walk down the widget hierarchy and unmake the Aqua controls, then mapping the frame into a new window should cause them all to get recreated. Note that I have seldom seen Mac applications that do this sort of thing, PhotoShop added the ability to move tabs in its tabbed palette windows from one palette to another. This was actually pretty useful at times. I think that some older versions of MS Word allowed you to drag toolbars off into palettes, but the Aqua version doesn't do this. The palettes are just separate floating windows, and the documents are not adorned with a whole bunch of gadgetry... I am not so moved by this use. >> >> >> Other: >> >> * *#110 "Tristate check/radiobuttons"* - Why is this targetted at >> Tk >> 9.0? Can't we have this for 8.5? > > You are right, I just need to get my butt in gear and implement this. > Again, I'd like to call for discussion then call for vote. This one would be useful. Jim -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
From: Donal K. F. <don...@ma...> - 2003-12-12 10:11:02
|
Brian Griffin wrote: >> * *#110 "Tristate check/radiobuttons"* - Why is this targetted at Tk >> 9.0? Can't we have this for 8.5? > > You are right, I just need to get my butt in gear and implement this. > Again, I'd like to call for discussion then call for vote. So it is an 8.5 candidate? Cool. Marked it as such. Donal. |
From: antirez <an...@in...> - 2003-12-11 16:01:35
|
On Thu, Dec 11, 2003 at 11:43:11AM +0000, Donal K. Fellows wrote: > * *#57 "Multi-Assign"* - If we make the syntax exactly that of > TclX's [lassign], I'd be happy to see this feature in the core. > In fact, I might even take on chasing this one down myself. > (There are several possible syntaxes, but I see absolutely no > reason to do anything other than the TclX style, especially as it > is probably fairly easy to compile and also has nice properties > relating to the result of the command.) What about to extend foreach to return a useful value (e.g. the not processed part of the list), and allows the last "script" argument to be omitted (defaulting to break)? There are many different ways to exactly implement it, some are described in wiki.tcl.tk/foreach > * *#117 "Object Type Introspection"* - This breaks the Tcl semantic > model, but since it is only a "for debugging" proposal that's not > necessarily a reason for an out-of-hand rejection. What about to implement this stuff introducing a new "internals" command? The command should be used only for debugging, and in general for stuff that doesn't guarantee to be portable across different platforms, Tcl versions, and so on. Example: puts [internals type $a] > * *#129 "New [binary] Format Codes"* - Things are happening with > this TIP. More on this list probably in the new year. I think [binary] also needs format codes to deal with unsigned integers. It is useful for direct manipulation of TCP/IP packets, or just to implement the DNS protocol in Tcl. The work around for now is to get two, or four bytes and using bitwise-or and shifting to create the integer. > * *#133 "Extending [expr] Operators"* - Taken in a narrow sense, a > new 'in' operator for list (a.k.a. set) membership is no problem. > In a wider sense, having the ability to install new operators > using scripts would be nice, but is much more complex to actually > do. I'm not 100% sure which the TIP is actually referring to. I have a different vision about it. IMHO Tcl, in the long term, should export all the math operators as commands because there is no need to do math as an exception. The same for math functions. [expr] will work just using the +, *, /, ... commands and so on (it will convert the infix expression to a Tcl script, and return the value.). This way to add a new operator is just a matter of define a new procedure. Since we are in the field of my fantasy... that's what I think: also, conditionals shouldn't have an implicit [expr]. For example the way [if] may work: if {> $a 5} {....}. But since [expr] is still there, when the expression is handy to write infix, one may write if {[expr ....]} {....}. Expr should be an utility for the (rare) times where you need to write a complex math expression. Not the default tha makes math-as-command non-existent. > * *#50 "Bundle [incr Tcl]"* - Requires effort from itcl people to > adapt to the core build mechanism and set up the rest of the > process (e.g. maintainer areas and assignments). I don't feel > like helping. I'm against this. [incr Tcl] is an useful and stable piece of code, but I don't think a C++ like OOP system is ideal for Tcl, that way to do OOP was invented to adapt a more powerful OOP system (the SmallTalk one) inside a low-level language, why should we bind Tcl with it?. At the same time, I prefectly agree with the author of the TIP that Tcl will be better with an OOP system in the core that we can consider as the standard way to do OOP programming with Tcl (but still other Tcl-only or as-extension OOP systems can be developed and used of course). I dunno what's the alternative, maybe none for now... but my feeling is that Tcl needs a more dynamic alternative for OOP, that feets more naturally inside the rest of Tcl. We should find something for Tcl that is concaptually what Clos is for Common Lisp. > * *#105 "[switch] Prefix Matching Style"* - I'm still not sure if > this is one of my good ideas or one of my bad ideas. It seems to me too specific to be implemented in [switch], and for all the other cases [switch] works in a different way, i.e. it stops once a match was reached (this can't be done here). Why don't implement it as a sub-command for string? Or just as a new command. Regards, Salvatore -- Salvatore Sanfilippo <antirez at invece dot org> "However, there is a tension between making the language simpler and making the organization of a system manifest. As the variety of costructs decreases, so does the variety of linguistic clues of a system's structure." (Ungar and Smith) |
From: Donal K. F. <don...@ma...> - 2003-12-12 14:18:12
|
antirez wrote: >On Thu, Dec 11, 2003 at 11:43:11AM +0000, Donal K. Fellows wrote: > > >> * *#57 "Multi-Assign"* - If we make the syntax exactly that of >> TclX's [lassign], I'd be happy to see this feature in the core. >> >> [...] >What about to extend foreach to return a useful value >(e.g. the not processed part of the list), and allows >the last "script" argument to be omitted (defaulting to break)? > > That'd be a substantial alteration to the behaviour of [foreach], large enough for me to be very unlikely to support it for 8.5. I'm not even sure if I'd support it for 9.0, as some people will be relying on [foreach] always having an empty result (e.g. people doing substitution into templates using [subst].) FWIW, if you insist on formally proposing this I'll insist on you doing so as a separate TIP, not as a modification to #57. But then I'd rather create a new command than do deep semantic alterations to an existing one. ([foreach] doesn't return any unprocessed elements because it always - modulo [break], [error] and [return] of course - processes all the elements. That's why you need [break] in the first place in our current multi-assignment "idiom"...) >> * *#117 "Object Type Introspection"* - This breaks the Tcl semantic >> model, but since it is only a "for debugging" proposal that's not >> necessarily a reason for an out-of-hand rejection. >> >> >What about to implement this stuff introducing a new "internals" >command? The command should be used only for debugging, and in >general for stuff that doesn't guarantee to be portable across >different platforms, Tcl versions, and so on. > > Such a command ought to be an extension if it is being done at all. But at that sort of level of debugging, I'd rather set a breakpoint and poke around with gdb... ;^) >> * *#129 "New [binary] Format Codes"* - Things are happening with >> this TIP. More on this list probably in the new year. >> >> >I think [binary] also needs format codes to deal with unsigned >integers. It is useful for direct manipulation of TCP/IP packets, >or just to implement the DNS protocol in Tcl. The work around for >now is to get two, or four bytes and using bitwise-or and shifting >to create the integer. > This ought properly to be the subject of a separate TIP. >We should find something for Tcl that is concaptually >what Clos is for Common Lisp. > Perhaps all we need to do is look into how to make Tcl-only OO extensions go faster. Small tweaks to the core might make a big difference. >> * *#105 "[switch] Prefix Matching Style"* - I'm still not sure if >> this is one of my good ideas or one of my bad ideas. >> >> >It seems to me too specific to be implemented in [switch], >and for all the other cases [switch] works in a different >way, i.e. it stops once a match was reached (this can't >be done here). > >Why don't implement it as a sub-command for string? Or just >as a new command. > > I sort of think of it being used like this: switch -prefix -- $option { -foo { #Handle the foo option } -bar { #Handle the bar option } -spong { #Handle the spong option } } To me, that feels very much like a normal switch command. All I've done is specified a different matching rule to the -exact, -glob and -regexp ones we currently support. It's better than the equivalent (modulo temporary variable names): #Alternative 1 - Tcl used to use strncmp() for prefix matching, so we can do the equivalent now set len [string length $option] if {$len > 1 && [string equal -length $len -- $option -foo]} { #Handle the foo option } elseif {$len > 1 && [string equal -length $len -- $option -bar]} { #Handle the bar option } elseif {$len > 1 && [string equal -length $len -- $option -spong]} { #Handle the spong option } #Alternative 2 - Manually expand each term into what actuallly matches it switch -exact -- $option { -f - -fo - -foo { #Handle the foo option } -b - -ba - -bar { #Handle the bar option } -s - -sp - -spo - -spon - -spong { #Handle the spong option } } It is also far better than the following (which I have seen) but I'll leave it up to you to spot why: if {[string match $option* -foo]} { #Handle the foo option } elseif {[string match $option* -bar]} { #Handle the bar option } elseif {[string match $option* -spong]} { #Handle the spong option } Donal. |
From: antirez <an...@in...> - 2003-12-13 09:28:15
|
On Fri, Dec 12, 2003 at 02:19:31PM +0000, Donal K. Fellows wrote: > That'd be a substantial alteration to the behaviour of [foreach], large > enough for me to be very unlikely to support it for 8.5. I'm not even > sure if I'd support it for 9.0, as some people will be relying on > [foreach] always having an empty result (e.g. people doing substitution > into templates using [subst].) If the problem is compatibility, the solution for 8.5, and in general until it is not possible to break the compatibility with the past, is: foreach varname list ?body? When the body argument is missing, foreach sets variables in the 'varname' list, with values in 'list', and returns a list composed of all the elements of 'list' not used to set variables. Otherwise the behaviour is exactly as in the past, i.e. an empty list is returned. > FWIW, if you insist on formally proposing this I'll insist on you doing > so as a separate TIP, not as a modification to #57. But then I'd rather > create a new command than do deep semantic alterations to an existing > one. ([foreach] doesn't return any unprocessed elements because it > always - modulo [break], [error] and [return] of course - processes all > the elements. That's why you need [break] in the first place in our > current multi-assignment "idiom"...) Since the foreach with break was an idiom for a long time, I think the above solution of the missing break can be acceptable: we don't introduce a new command, users will start to learn that in case of the well-known assignment idiom of foreach, they can just avoid the final break. Eventually all will understand that in such a special form of foreach, there is a meaningful return value that can be used to get the not processed part of the list. Btw I'll try to write a TIP about it. What I care more, is that the new command will be in the form: command varlist valuelist instead of something like command var1 var2 var3 ... varN valuelist To map a list of variable names with a list of values is logical. When the variable names are immediate values, to write { and } don't hurt, instead, to need expansion when variable names are contained in a list is IMHO not nice. > Such a command ought to be an extension if it is being done at all. But > at that sort of level of debugging, I'd rather set a breakpoint and poke > around with gdb... ;^) But to do very special stuff, it can be interesting to have the ability to insepct internals. See for example the following: http://mini.net/tcl/9549 That needs the ability to know how space the internal representation of an object is using to work better. In general the 'internals' command may help developers that are trying to show a possible advanced change of Tcl implemented in pure Tcl. Btw, nothing with high priority of course... ;) > >We should find something for Tcl that is concaptually > >what Clos is for Common Lisp. > > > Perhaps all we need to do is look into how to make Tcl-only OO > extensions go faster. Small tweaks to the core might make a big difference. That's a great idea. > I sort of think of it being used like this: > > switch -prefix -- $option { > -foo { #Handle the foo option } > -bar { #Handle the bar option } > -spong { #Handle the spong option } > } > > To me, that feels very much like a normal switch command. All I've done With the difference that while switch with -exact, glob, or regexp, performs a sequential search, -prefix will scan all the "patterns" before to return. What I mean is that we can immagine a version of switch with a -command option, where the command is used to perform the matching between the string and the patterns. All the old options of switch can be implemented like this, but not the -prefix one. It looks the same from the user point of view but adds something of new to the semantic of switch. > is specified a different matching rule to the -exact, -glob and -regexp > ones we currently support. It's better than the equivalent (modulo > temporary variable names): > > #Alternative 1 - Tcl used to use strncmp() for prefix matching, so we > can do the equivalent now [snip] > #Alternative 2 - Manually expand each term into what actuallly matches it > switch -exact -- $option { [snip] > It is also far better than the following (which I have seen) but I'll > leave it up to you to spot why: > > if {[string match $option* -foo]} { > #Handle the foo option > } elseif {[string match $option* -bar]} { > #Handle the bar option > } elseif {[string match $option* -spong]} { > #Handle the spong option > } Yeah... very ugly, and the last just can't work as expected in all the cases. My suggestion is: string prefix $option {-foo -bar -spong} that will return the matching option, or an empty string if there isn't a match or there are multiple matches. So: set optlist {-foo -bar -spong} switch -- [string prefix $option $optlist] { -foo { #Handle the foo option } -bar { #Handle the bar option } -spong { #Handle the spong option } } possibly adding an option to 'string prefix' to return a list of all the matches, when there are more then one, so the default branch of the switch may be: default { puts stderr "Ambiguous option $option, among:" foreach t [string prefix -all $options $optlist] { puts "\t$t" } } Rationale: 1) We are not adding something of new, nor something of semantically new to [switch], but the usability is nearly the same. 2) [string prefix] is a general way to perform prefix-matching without to require a control structure. Programmers will find some way to use it alone probably. 3) As long as it's just a special case of string matching, seems more appropriate to have it inside the [string] command. Cheers, Salvatore -- Salvatore Sanfilippo <antirez at invece dot org> "However, there is a tension between making the language simpler and making the organization of a system manifest. As the variety of costructs decreases, so does the variety of linguistic clues of a system's structure." (Ungar and Smith) |
From: Michael A. C. <mi...@cl...> - 2003-12-11 16:05:52
|
On Thu, 11 Dec 2003, Donal K. Fellows wrote: > * *#149 "enabled==normal in -state"* - I think this is a really bad > idea, but then I also know some of what Joe English has been up to > with the style engine, and that work is completely incompatible > with this TIP. As the submiter of #149, I've been persuaded that it isn't a good idea. Can the state be changed to withdrawn, or can we have a quick vote where it gets soundly rejected? Michael |
From: Jim I. <ji...@ap...> - 2003-12-11 18:36:09
|
On Dec 11, 2003, at 3:43 AM, Donal K. Fellows wrote: > * *#51 "Native Mac Menubutton"* - Would a Mac Tcler like to comment > on whether this has been obsoleted by the move to MacOSX? > We use the native menubutton on Mac OS X. This doesn't really obsolete the Tip for Classic MacOS, since that doesn't help folks who still rely on Classic MacTk. We just aren't much working on Classic Tk much any more. The replacement code takes fewer options than the current code does (note that these restrictions pretty much apply to the AquaTk implementation as well...) So we need to decide (a) whether we are even working on Classic MacTk or not any more, and THEN on (b) whether if we are, how folks who use it feel about the tradeoff of proper L&F vrs. losing a few options (-bitmap & -image). Jim -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
From: Jeff H. <jeffh@ActiveState.com> - 2003-12-11 19:10:58
|
Jim Ingham wrote: ... > So we need to decide (a) whether we are even working on Classic MacTk > or not any more, and THEN on This is something I've meant to ask on tcl-core for a while ... we need either a new commited maintainer for Mac OS 8/9 (Classic Mac), or we need to drop it for 8.5+. Looking in the ChangeLogs, Daniel Steffen was the last person to update the Mac build system - for Tcl 8.4.1. It hasn't been updated in over a year. Like Win95 and other such proprietary systems, we have to focus our energy on can be practically maintained. At this point, there is noone willing to maintain Mac OS 8/9. If someone is willing to step up, we can keep it around. Otherwise I think we best declare that Tcl/Tk 8.4 was the last version to support Classic Mac and move on, focusing on top-notch Aqua support. IIUC, OS 9 is only available from Apple now in a legacy mode. I can't see a specific end-of-life for it, but all the apple.com stuff points to dual-boot usage with OS X. Any takers? Jeff |
From: Jim I. <ji...@ap...> - 2003-12-11 19:25:28
|
Jeff, I am pretty sure the eMacs (the low-cost All-In-One CRT based model that was originally intended only for the education market) still boot into Mac OS 9. The iBooks may too, I am not sure about this. But the Powerbooks & all the Towers no longer boot into 9. You can run Classic MacOS apps in an emulation environment inside X on all these machines, of course, and that will be supported for a long time. But it doesn't make much sense to run Classic MacTk if you can run AquaTk just as easily... Daniel is on vacation, so we should wait on him for final word. But we have both discussed calling the 8.4 releases the last supported version or Classic MacTk. I think that concentrating our efforts on AquaTk is probably the best use of our resources. Of course, if somebody else is interested, and willing to do the work, that would be fine. And we should ping the Mac Tcl Mailing list to see if anyone is likely to step up. But I don't think we are likely to find anybody... Jim On Dec 11, 2003, at 11:06 AM, Jeff Hobbs wrote: > Jim Ingham wrote: > ... >> So we need to decide (a) whether we are even working on Classic MacTk >> or not any more, and THEN on > > This is something I've meant to ask on tcl-core for a while ... > we need either a new commited maintainer for Mac OS 8/9 (Classic > Mac), or we need to drop it for 8.5+. > > Looking in the ChangeLogs, Daniel Steffen was the last person to > update the Mac build system - for Tcl 8.4.1. It hasn't been > updated in over a year. > > Like Win95 and other such proprietary systems, we have to focus > our energy on can be practically maintained. At this point, there > is noone willing to maintain Mac OS 8/9. If someone is willing to > step up, we can keep it around. Otherwise I think we best declare > that Tcl/Tk 8.4 was the last version to support Classic Mac and > move on, focusing on top-notch Aqua support. > > IIUC, OS 9 is only available from Apple now in a legacy mode. I > can't see a specific end-of-life for it, but all the apple.com > stuff points to dual-boot usage with OS X. > > Any takers? > > Jeff > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
From: Jeff H. <jeffh@ActiveState.com> - 2003-12-11 19:37:20
|
> I am pretty sure the eMacs (the low-cost All-In-One CRT based model > that was originally intended only for the education market) still boot > into Mac OS 9. The iBooks may too, I am not sure about this. But the > Powerbooks & all the Towers no longer boot into 9. You can From looking at Apple's site, it appears that, at least with Panther and the latest iBook releases, all machines (eMacs too) come with Panther. No mention of OS 9 is even made. > Daniel is on vacation, so we should wait on him for final word. But we ... > that would be fine. And we should ping the Mac Tcl Mailing list to see Right, we'll wait for further word. Jeff |
From: Jim I. <ji...@ap...> - 2003-12-11 19:43:45
|
Jeff, On Dec 11, 2003, at 11:30 AM, Jeff Hobbs wrote: >> I am pretty sure the eMacs (the low-cost All-In-One CRT based model >> that was originally intended only for the education market) still boot >> into Mac OS 9. The iBooks may too, I am not sure about this. But the >> Powerbooks & all the Towers no longer boot into 9. You can > > From looking at Apple's site, it appears that, at least with Panther > and the latest iBook releases, all machines (eMacs too) come with > Panther. No mention of OS 9 is even made. Panther comes with a full version of OS 9 so that you can run applications in Classic mode, and Classic mode is supported on all shipping machines. I don't think that support for booting into Mac OS 9 is being added to any new machines, so the only ones it is going to work on are ones that it hasn't broken on by virtue or some new hardware that was added... (Note, I don't know if this is official Apple policy, I am just reporting my observations as a watcher of the Mac scene.) > >> Daniel is on vacation, so we should wait on him for final word. But >> we > ... >> that would be fine. And we should ping the Mac Tcl Mailing list to >> see > > Right, we'll wait for further word. Yes, but you are right we really should make a decision on this in the new year. Jim -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
From: Jeff H. <jeffh@ActiveState.com> - 2003-12-11 19:25:36
|
> * *#133 "Extending [expr] Operators"* - Taken in a narrow sense, a > new 'in' operator for list (a.k.a. set) membership is no problem. > In a wider sense, having the ability to install new operators > using scripts would be nice, but is much more complex to actually > do. I'm not 100% sure which the TIP is actually referring to. I would prefer to just focus on specific operations like 'in'. I'm not sure that you could make a very efficient implementation of this, and it somewhat conflicts with the general command mechanism already in Tcl. Jeff |
From: Joe E. <jen...@fl...> - 2003-12-11 19:32:21
|
Donal K. Fellows wrote: > [Re: TIP Round-Up ] > * *#39 "-component Option to Tk Widgets"* - Would someone with > experience of megawidget construction please comment on this TIP? #39 isn't fully cooked; the TIP basically says "let's add a new standard resource and figure out what to do with it later." If the point is to fix focus and keyboard traversal issues in megawidgets, the TIP should propose new algorithms for focus management and explain exactly how the "-component" resource is to be interpreted. My advice: fix or withdraw. > * *#42 "-clientdata Option to Tk Widgets"* - Would someone with > experience of megawidget construction please comment on this TIP? #42 would be of limited utility. From the Rationale section: | The only way to accomplish a similar feat[ure] today is by | storing data in a global or namespace variable keyed by widget | name. This doesn't lend itself very well to general purpose | library routines. But storing data in a namespace variable is precisely what you _want_ to do for general-purpose libraries. Any library that used the "-clientdata" resource would be incompatible with every other library that did the same thing. If #42 were reworked to involve dictionaries somehow, it might be a better idea. My advice: withdraw. > * *#38 "Default Bindtags"* - Would someone with experience of > megawidget construction please comment on this TIP? It's not clear to me how changing the default bindtags would provide any functionality that's not already possible by changing the default bindings. #38 also seems rather dangerous -- it would have many unintended consequences (for instance, breaking keyboard accelerators in dialogs). My advice: withdraw. > * *#57 "Multi-Assign"* - If we make the syntax exactly that of > TclX's [lassign], I'd be happy to see this feature in the core. This one is a good idea, but the syntaxes proposed in the TIP aren't so good: "Extended set" is not backwards-compatible, and [assign ?switches? <varlist> <valuelist>] is just plain awful. [mset] is OK, but TclX's [lassign] is better. My advice: amend the TIP to specify [lassign] syntax. > * *#70 "Relational Switch"* - I believe this properly belongs in the > domain of tcllib or some other extension. Agreed. This doesn't belong in the core. > * *#117 "Object Type Introspection"* - This breaks the Tcl semantic > model, but since it is only a "for debugging" proposal that's not > necessarily a reason for an out-of-hand rejection. Once again, I strongly object to this TIP on the grounds that people will use it. This TIP would expose internal implementation details that we really want to keep hidden. > * *#119 "Angled Canvas Text"* - I worry about portability with this, > but it would be nice to have. This one will be a beast to implement on X11, at least until Cairo support is widespread. > * *#132 "Floating-Point Conversion Improvement"* - Apparently this > is a real bear to implement. :^( I'd really like to see this fixed. > * *#134 "Subsystem Per-Thread Data Interfaces"* - I don't like > this. IMHO subsystems should keep themselves to themselves, only > exposing their internal state through a well-defined per-subsystem > API. A Really Bad Idea. We should be _removing_ instances of thread-specific data wherever possible, not using more of it. > * *#140 "Tracing Namespace Mods"* - I might defer or withdraw this TIP. I really worry about unforeseen consequences with this one. TIP #62 "Add Support for Command Tracing" introduced lots of new bugs, since operations that were previously "safe" can now reenter the interpreter. Adding even more trace hooks makes me nervous. > * *#143 "Resource Limiting Framework"* - I need to do some > implementation work on this one. Which means I need to find a few > days worth of free time... I still don't think this is a good idea: it's trying to solve the problem in the wrong place. > * *#152 "-detail Option to tk_messageBox"* - I'd love to see this > (which would be trivial on Unix.) All we need is a plan for what > to do on Windows where things are much less flexible than > everywhere else. This is a really good idea. I'm willing to contribute a Unix implementation, if nobody else gets around to it before I do... --Joe English jen...@fl... |
From: Jim I. <ji...@ap...> - 2003-12-11 19:37:09
|
IIRC, there is an implementation of this in BLT. George will know for sure. Jim On Dec 11, 2003, at 11:32 AM, Joe English wrote: >> * *#119 "Angled Canvas Text"* - I worry about portability with >> this, >> but it would be nice to have. > > This one will be a beast to implement on X11, at least > until Cairo support is widespread. > > -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
From: Jeff H. <jeffh@ActiveState.com> - 2003-12-11 19:45:31
|
> >> * *#119 "Angled Canvas Text"* - I worry about portability with ... > IIRC, there is an implementation of this in BLT. George will > know for sure. There is, but BLT doesn't work on the Mac, and I think the inclination was to use the native text rotation features of text drawing (BLT draws the rotated text into a bitmap). That could be used as a fallback though. Jeff |
From: Jim I. <ji...@ap...> - 2003-12-11 21:40:43
|
Jeff, On Dec 11, 2003, at 11:43 AM, Jeff Hobbs wrote: >>>> * *#119 "Angled Canvas Text"* - I worry about portability with > ... >> IIRC, there is an implementation of this in BLT. George will >> know for sure. > > There is, but BLT doesn't work on the Mac, and I think the > inclination was to use the native text rotation features of > text drawing (BLT draws the rotated text into a bitmap). > That could be used as a fallback though. Yes, that's what I had in mind, since I think on both Windows & Mac OS X you get text rotation for free. Even on X11 we could test for Server extensions that handle this, but we will need a fallback. Jim > > Jeff > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
From: Jeff H. <jeffh@ActiveState.com> - 2003-12-11 19:50:32
|
> > * *#140 "Tracing Namespace Mods"* - I might defer or withdraw this > > TIP. > > I really worry about unforeseen consequences with this one. > TIP #62 "Add Support for Command Tracing" introduced lots > of new bugs, since operations that were previously "safe" > can now reenter the interpreter. Adding even more trace > hooks makes me nervous. While I don't think we need 'namespace' tracing, I do plan to submit a TIP that would make further changes on top of TIP #62. While it was buggy going in, it does provide some useful introspection/control at the Tcl level. What I want to add is the ability to modify the args in/result out. We can't balk at useful updates because of their complexity, but we need to be vigilant on testing, testing, testing, and making sure that the bigger the TIP change, the earlier it goes into the release stream pre-final. Jeff |
From: Jeff H. <jeffh@ActiveState.com> - 2003-12-11 20:01:17
|
I just want to back up Joe that related TIP #39 && #42 are not generally useful. They are not composable and have issues relating to their lack of ubiquity. #39 fails for the same reason that I feel -tooltip or -dragndrop behaviors are best not applied as widget options, but with an external command. Using an external command, any existing widget can be used for the new functionality. That said, we do need some functionality for megawidgets to redirect focus and events reliably. Bindtags and bindings can be manipulated to deal with some events, but it could be made much easier (allowing more megawidgets to behave "properly") and focus handling is still an issue. Jeff > > * *#39 "-component Option to Tk Widgets"* - Would someone with > > experience of megawidget construction please comment on this > > TIP? > > #39 isn't fully cooked; the TIP basically says "let's add > a new standard resource and figure out what to do with it later." > > If the point is to fix focus and keyboard traversal issues in > megawidgets, the TIP should propose new algorithms for focus > management and explain exactly how the "-component" resource > is to be interpreted. My advice: fix or withdraw. > > > * *#42 "-clientdata Option to Tk Widgets"* - Would someone with > > experience of megawidget construction please comment on this > > TIP? > > #42 would be of limited utility. From the Rationale section: > > | The only way to accomplish a similar feat[ure] today is by storing > | data in a global or namespace variable keyed by widget name. This > | doesn't lend itself very well to general purpose library routines. > > But storing data in a namespace variable is precisely what > you _want_ to do for general-purpose libraries. Any library > that used the "-clientdata" resource would be incompatible > with every other library that did the same thing. > > If #42 were reworked to involve dictionaries somehow, it > might be a better idea. My advice: withdraw. |
From: Donal K. F. <don...@ma...> - 2003-12-12 10:43:49
|
Joe English wrote: >> * *#57 "Multi-Assign"* - If we make the syntax exactly that of >> TclX's [lassign], I'd be happy to see this feature in the core. >> >> >This one is a good idea, but the syntaxes proposed in the >TIP aren't so good: "Extended set" is not backwards-compatible, >and [assign ?switches? <varlist> <valuelist>] is just plain >awful. [mset] is OK, but TclX's [lassign] is better. >My advice: amend the TIP to specify [lassign] syntax. > If I take it over (high likelihood, especially given that I'd be its maintainer) that's exactly what I'll do. :^D >> * *#119 "Angled Canvas Text"* - I worry about portability with this, >> but it would be nice to have. >> >> >This one will be a beast to implement on X11, at least >until Cairo support is widespread. > If we only support the "cardinal" angles (i.e. the multiples of 90 degrees), it isn't too hard. Just computation time. If anything like the XRender extension is available, it should be possible to do the job properly and support arbitrary angling of texts. There is also a suggestion (on the Tk9.0 suggestions page) on the Wiki that Tk should use Zinc (which is OpenGL-based) as the foundation for its canvas. I'm still not sure about the implications for licensing, and there may well be a load of other lurking problems. >> * *#143 "Resource Limiting Framework"* - I need to do some >> implementation work on this one. Which means I need to find a few >> days worth of free time... >> >> >I still don't think this is a good idea: it's trying >to solve the problem in the wrong place. > Out of curiosity, what do you think is the right place to solve this? >> * *#152 "-detail Option to tk_messageBox"* - I'd love to see this >> (which would be trivial on Unix.) All we need is a plan for what >> to do on Windows where things are much less flexible than >> everywhere else. >> >> >This is a really good idea. I'm willing to contribute >a Unix implementation, if nobody else gets around to it >before I do... > The Unix implementation doesn't worry me; it's a few minutes Tcl hacking. :^) It's what to do on Windows that stops me from pushing this one forward. Is it possible to subclass the standard message box and add the behaviour? Or is there some kind bizarre hack in the Win guts that can be done instead? (There's nothing obvious in the API - I've already checked - but some kinds of possibilities may well be invisible to me due to my background in Unix.) Donal. |
From: Vince D. <vi...@sa...> - 2003-12-12 11:15:20
|
> The Unix implementation doesn't worry me; it's a few minutes Tcl > hacking. :^) It's what to do on Windows that stops me from pushing > this one forward. Is it possible to subclass the standard message box > and add the behaviour? Or is there some kind bizarre hack in the Win > guts that can be done instead? (There's nothing obvious in the API - > I've already checked - but some kinds of possibilities may well be > invisible to me due to my background in Unix.) Worst case is that we just concatenate the -message and -detail (perhaps with '\n\n' in between). That would achieve the same effect, but with both messages in the same size font. Vince. |