Tcl-URL! - weekly Tcl news and links (Jun 12)
Uwe Klein
If you want full obfuscation, just write it
in Perl. Bill Poser on c.l.t
http://groups.google.com/group/comp.lang.tcl/msg/88bac5d12ddf94a6
Standards are GREAT! And, there's soooooooo
many to choose from!! Allodoxaphobia on c.l.t
http://groups.google.com/group/comp.lang.tcl/msg/21dc026fb1e67e30
POTW:
ANNOUNCE: TclRAL Version 0.8.3 by Andrew Mangogna
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/e1e6dd5a065479c0
TclRAL is a "C" based extension to Tcl that makes available a Tuple and
Relation data types as native Tcl objects and supplies a complete set of
relational algebraic operators for these types.
Version 0.8.3 is primarily a bug fix release, however several new
commands were added. Most notable is "relation compose" which rounds
out the "relation join" family of commands (i.e. join, semijoin, semiminus
and compose).
The project is hosted at Sourceforge and the TEA compliant source package
as well as precompiled binaries for both Linux and Windows compiled against
both Tcl 8.4 and Tcl8.5 are available there.
Homepage:
http://sourceforge.net/projects/tclral
ORBI: or what happened on comp.lang.tcl
Expr without braces
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/5cb65a987270d2f
nahh, never
stdin stdout on windows
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/47d2955217b5d2f5
some explanations, some tricks
regexp standards
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/2885f022bea71b3c
see QOTW ;-))
ISO: technique to pass multiple arguments to a windows bat file
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/781d7461ac83a7eb
rites of a faint religion.
Will TCL UDP Extension 1.0.6 support HPUX?
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/6d8b4a6a643765c3
er, yes from 1.0.9 onwards.
Tclet logging -- How?
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/bf6d16e32b96af61
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/b814e783d2bae2d3
TIPX: new, used and discarded Tips
nothing new here, walk on.
OOTW: Orphan of the week or questions nobody answered yet:
USB-UIRT
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/2ec21710f1ca2c74
Expect/Tkterm screen scraping?
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/a00c612a69df6c67
Thanks to Arjen Markus for his weekly reports on the Wikis:
One nice new feature of the Wiki struck your chronicler the other
day: if you search for a term that is used in a lot of pages, you
can now get the next batch and the next and the next ...
A bit on Wikis and stuff
- If you want a new feature in Wikit, why not add it yourself?
Here is one with chapters: <http://wiki.tcl.tk/19593>
- Okay, there seems to be some written material on Jacl.net.
But where? Just another secret of the Tcl community at
<http://wiki.tcl.tk/13178>
- Tcl as a glue language? COM On, see for yourself:
<http://wiki.tcl.tk/4094> is the penultimate demonstration
of different extensions cooperating to produce a small,
if not tiny, web browser.
Bits on OO, maths, games
- For anyone interested in OO programming with Tcl, the
page on TIP #257 is a must - <http://wiki.tcl.tk/14754>
But from there on there are lots of other pages to enjoy,
like <http://wiki.tcl.tk/18440>
- Expect is an amazing extension to Tcl. One of the applications
is a way to disassociate a program from the console you started
it on - making it run independently. See:
<http://wiki.tcl.tk/9263> for details.
- Relational algebra has some nice applications, here is a
way to detect all header files a C soure file depends on:
<http://wiki.tcl.tk/18203> as a demonstration of a more
general principle.
- Mazes are fun and intricate ... and you can change them during
this game - <http://wiki.tcl.tk/10442> (or doesn't it work yet?)
- Carry data around and not feel the burden? Well, maybe all it
requires is a bit of TAO - <http://wiki.tcl.tk/19536>
- For those among us who read French, <http://wfr.tcl.tk/1376>
holds a translation of a little story about a few hard-working
Tclers.
Everything Tcl-related you want is probably one or two clicks away in these
pages:
The "Welcome to comp.lang.tcl" message by Andreas Kupries
http://www.purl.org/net/tcl-welcome
comp.lang.tcl is a crucial resource for Tcl practitioners.
An interesting perspective on its traffic appears at
http://groups.google.com/group/comp.lang.tcl/about
The Tcl Developer Site is Tcl's "home base".
http://www.tcl.tk
Larry Virden maintains a comp.lang.tcl FAQ launcher.
http://www.purl.org/NET/Tcl-FAQ/
The Tcl Developer Xchange is a highly organized resource center
of documents and software with provisions for individuals to
maintain references to their own software:
http://www.tcl.tk/resource/
The TDX sponsor, ActiveState, also keeps info to convince your
boss Tcl is a good thing
http://www.tcl.tk/scripting/
The Tcl'ers Wiki is a huge, dynamic, collaboratively edited repository
of documentation, examples, tutorials and pontifications on all things
Tcl.
http://wiki.tcl.tk/0
For the ideal overview of the topics about Tcl most likely to
interest a newcomer, see "Arts and Crafts ..."
http://wiki.tcl.tk/969
There's also a high-quality Wikibook on Tcl:
http://en.wikibooks.org/wiki/Programming:Tcl
ActiveState maintains binaries distribution and development tools
http://www.activestate.com/Tcl
along with a Cookbook of Tcl recipes
http://aspn.activestate.com/ASPN/Cookbook/Tcl
"La Gazette du Técleux" is an important monthly publication.
http://wfr.tcl.tk/1159
deli.cio.us presents an intriguing approach to reference commentary.
It already aggregates quite a bit of Tcl intelligence.
http://del.icio.us/tag/tcl
Cameron Laird tracks several Tcl/Tk references of interest (but
needs to validate many of the links).
http://phaseit.net/claird/comp.lang.tcl/
Years ago, Cetus Links maintained a Tcl/Tk page with verified links
http://www.cetus-links.org/oo_tcl_tk.html
"Yahoo! Groups" archives comp.lang.tcl.announce posts--even
though clta itself is dormant.
http://groups.yahoo.com/group/tcl_announce/
We're working on more useful archives of past installments. In the
meantime, an alternative is
http://groups.google.com/groups?oi=djq&as_q=+Tcl-URL&as_ugroup=comp.lang.tcl
Suggestions/corrections for next week's posting are always welcome.
To receive a new issue of this posting in e-mail each Monday, ask
<cla...@phaseit.net> to subscribe. Be sure to mention "Tcl-URL!".
--
Phaseit, Inc. (http://phaseit.net) is pleased to participate in and
sponsor the "Tcl-URL!" project.
Donal K. Fellows
> TIPX: new, used and discarded Tips
> nothing new here, walk on.
A correction: there has been a new TIP published (#306: Auto-Naming
Widgets) but the publication is stuck because of a mailing list outage
at SourceForge.
Donal.
Bryan Oakley
That's really interesting. In all my years of doing Tk, I don't think
I've ever wished for that feature. I'm not saying the TIP is good or
bad, I'm just making an observation.
I can see how it would be handy, though the TIP says it won't guarantee
a unique name which seems very odd ("Note that there is no protection
against already existing window names"). I would think it best if it
worked like automatic image names where the system always picks a new,
unique name.
--
Bryan Oakley
http://www.tclscripting.com
Alexandre Ferrieux
> Donal K. Fellows wrote:
>
> > A correction: there has been a new TIP published (#306: Auto-Naming
> > Widgets) but the publication is stuck because of a mailing list outage
> > at SourceForge.
>
> I've ever wished for that feature. I'm not saying the TIP is good or
> bad, I'm just making an observation.
>
> I can see how it would be handy, though the TIP says it won't guarantee
> a unique name which seems very odd ("Note that there is no protection
> against already existing window names"). I would think it best if it
> worked like automatic image names where the system always picks a new,
> unique name.
I'd cross the canyon and admit I'm against this. The whole thing can
be simply approximated in pure Tcl by renaming the proposed 'autoname'
to '%':
set frame [frame [%] ...]
Sure, [%] is not as elegant as .% (actually, it's just 66% as
elegant ;-)
But asking for new code in Tk for this sounds irresponsible.
-Alex
Koen Danckaert
> I've ever wished for that feature. I'm not saying the TIP is good or
> bad, I'm just making an observation.
Well, I've been longing for such a feature a long time, otherwise I wouldn't have submitted the TIP :-)
I find it really annoying to have to define a name for a widget, when that name is in fact irrelevant (i.e. not used in the rest of the code). A widget is usually assigned to a variable, and only referred to by that variable. The variable often gets the same name as the widget, sometimes a slightly different name, sometimes a completely different one. This certainly doesn't improve the readability (and writability) of the code.
When the name of the variable is changed for some reason, you have the option of also changing the name of the widget, or leaving it as it is, increasing potential confusion.
I've in fact been using the patch in the TIP for about half a year now, and I wouldn't want to go back. Of course, I can only speak for myself here, but my personal observation is that I use the auto-naming feature for about 90% of the widgets.
> I can see how it would be handy, though the TIP says it won't guarantee
> a unique name which seems very odd ("Note that there is no protection
> against already existing window names"). I would think it best if it
> worked like automatic image names where the system always picks a new,
> unique name.
It guarantees a unique name as long as you don't intermix "normal" and "automatic" names. Numbers are not normally used as widget names, so I don't see a problem here. If you really want to use numbers for normal names, you can still use a prefix for the automatic names:
frame .1
frame .2
frame ._%
(Of course, if really needed, the implementation could change on this point.)
Koen
Koen Danckaert
> be simply approximated in pure Tcl by renaming the proposed 'autoname'
> to '%':
>
> set frame [frame [%] ...]
>
> Sure, [%] is not as elegant as .% (actually, it's just 66% as
> elegant ;-)
Using a short procedure name like "%" has the drawback that extensions or modules which you want to incorporate in your code, may already have defined "%" for something else. Also, as each module may have its own autonaming scheme, there is a risk for overlapping widget names. So I really think auto-naming belongs in the core.
Note that Tcl/Tk already uses auto-naming for other things, e.g. for channels and for images.
Another note: In Python's Tk implementation (Tkinter), automatic widget names are the default. For example, a label is normally created as:
mylabel = Label(parentframe, text="koen")
In this case the Tk widget name will be something like $parentframe.123
Only if you really want to assign a name yourself, you can use:
mylabel = Label(parentframe, text="koen", name = "mylabel")
I think the Python guys got it right on this point...
Koen
Bryan Oakley
> ...
> A widget is usually assigned to a variable, and only referred to by that
> variable.
That's not necessarily true. "usually" is perhaps a bit strong of a
term. I regularly write code where I explicitly use hard-coded widget
paths (*) and do not store them in widgets. Frankly, I find it quite
liberating.
Truth be told, I usually use a mix. I use hard-coded paths for
"significant" widgets, and store paths in variables for dynamic widgets
(eg: notebook tabs). Everything else is usually some combination --
sometimes it's $parentWidget.hardcoded-child, sometimes it's
$parentWidget.l1, ...l2, ...l3, or .main.label[incr n], etc.
(*) Yeah, yeah, I know I wrote a wiki page extolling the virtues of
storing widget paths in variables a few years back, but some comments on
that page convinced me the folly of my ways :-)
> The variable often gets the same name as the widget,
another generality that isn't necessarily true. If I use variables, I
virtually never use one with the same name as the widget.
I'm not saying you're wrong, just that there are many ways to write Tk code.
> sometimes
> a slightly different name, sometimes a completely different one. This
> certainly doesn't improve the readability (and writability) of the code.
>
> When the name of the variable is changed for some reason, you have the
> option of also changing the name of the widget, or leaving it as it is,
> increasing potential confusion.
>
If you never try to sync variable names and widget names in the first
place, that point is moot.
For example, when I use variables I always use a single array. I may
have code that looks something like this:
set w(statusbar) .foo.bar.status
set w(text) .baz.text
set w(name) .whatever.e1
set w(address) .whatever.e2
...
In fact, the main reason I originally started using variable names was
specifically so I could change the widget names without having to change
references to the widget. I find that during early stages of
development, widget names tend to change a lot. Storing them in
variables allowed me to change them willy-nilly without affecting other
code that manipulates those widgets.
The point being, there are many, many ways to organize widgets.
Thankfully! I know my style has morphed over the years. For some,
auto-generated names will be a godsend, for others it will be an
unnecessary feature. For most, I suspect we would continue to use a
mixture of specific names sometimes, auto-generated names other times.
It's a useful feature, just not something that is universally needed.
>
> I've in fact been using the patch in the TIP for about half a year now,
> and I wouldn't want to go back. Of course, I can only speak for myself
> here, but my personal observation is that I use the auto-naming feature
> for about 90% of the widgets.
>
>
>> I can see how it would be handy, though the TIP says it won't
>> guarantee a unique name which seems very odd ("Note that there is no
>> protection against already existing window names"). I would think it
>> best if it worked like automatic image names where the system always
>> picks a new, unique name.
>
>
> It guarantees a unique name as long as you don't intermix "normal" and
> "automatic" names. Numbers are not normally used as widget names,
Again, careful with those generalities! I use numbers as part of widget
paths quite frequently (though admittedly, most places where I do would
be a good candidate to use this new feature).
I think it would be a critical flaw if the auto-generated name wasn't
guaranteed to be unique. Package authors couldn't depend on this
feature, for example, since they wouldn't know what naming conventions
might be in use for the program. And anyone who uses packages couldn't
in good conscience use automatic names since they wouldn't know what
names a package might use. I think having the auto-name-generator
potentially pick a name that is in use would be a show-stopping feature.
Still, I applaud your effort to not only suggest a useful feature but to
also back it up with code. The opinion of someone who write code always
carries more weight than the opinion of folks like me who just cheer
from the sidelines :-)
--
Bryan Oakley
Andreas Leitgeb
> I'd cross the canyon and admit I'm against this. The whole thing can
> be simply approximated in pure Tcl by renaming the proposed 'autoname'
> to '%':
> set frame [frame [%] ...]
That's no solution, because you still have to pass through
the new frame's parent, and you surely wouldn't suggest to
creat such a %-procedure for each and every parent :-)
I favour the TIP. (but then, I'm one of the type for whom
finding names for things is the toughest part of programming)
Bruce Hartweg
I'll also mention that
1) I never really needed this before,
2) if it exists I can maybe see using it sometimes,
3) it would be very very very bad if the autoname returned an existing widget.
I know it make the implementation easier but that is a nightmare bug waiting to bite someone.
I add some widget somwhere and I have to be careful that nowhere else is the autoname feature
being used, and/or if I want to use autoname I have to be careful no other widget is geing
named that way and in both cases I have to no the inner implementation details of the autoname
functionality itself. if it is autoname - i should NOT care if it is a number or a random
string. it seems it wouldn't be that hard in the implementation to add a check for existing widget
and keep incrementing until an unused one was found.
Bruce
Koen Danckaert
> Truth be told, I usually use a mix. I use hard-coded paths for
> "significant" widgets, and store paths in variables for dynamic widgets
> (eg: notebook tabs). Everything else is usually some combination --
> sometimes it's $parentWidget.hardcoded-child, sometimes it's
> $parentWidget.l1, ...l2, ...l3, or .main.label[incr n], etc.
Well, I've also had code where I used .l1, .l2, .l3,etc. And afterwards I wanted to insert another widget in between... Of course, I could simply insert a .l7 between .l2 and .l3, but that leads to crappy code.
Using .l[incr n] partly solves this, but I wanted a more general solution, which is also usable when different procedures create widgets in the same parent.
> I'm not saying you're wrong, just that there are many ways to write Tk
> code.
> [...]
> The point being, there are many, many ways to organize widgets.
> Thankfully! I know my style has morphed over the years. For some,
> auto-generated names will be a godsend, for others it will be an
> unnecessary feature. For most, I suspect we would continue to use a
> mixture of specific names sometimes, auto-generated names other times.
>
> It's a useful feature, just not something that is universally needed.
That's certainly true.
In my coding style, it comes in very handy, but I still use specific names in some cases. I'm certainly not proposing to deprecate those :-)
> Again, careful with those generalities! I use numbers as part of widget
> paths quite frequently (though admittedly, most places where I do would
> be a good candidate to use this new feature).
>
> I think it would be a critical flaw if the auto-generated name wasn't
> guaranteed to be unique. Package authors couldn't depend on this
> feature, for example, since they wouldn't know what naming conventions
> might be in use for the program. And anyone who uses packages couldn't
> in good conscience use automatic names since they wouldn't know what
> names a package might use. I think having the auto-name-generator
> potentially pick a name that is in use would be a show-stopping feature.
Not if the auto-generator is in the core, and it's generally known that it generates names consisting of numbers. I'd like to refer to Python/Tkinter and Ruby/Tk, where auto-naming is the default, and where everybody knows that the auto-names are numbers. So nobody uses numbers when manually overriding a widget's name.
Of course, existing extensions in Tk may already use names consisting of numbers. Or you may have code where numbers are used, and which you want to extend with new code using auto-names. So I'm certainly willing to change this part of the implementation.
> Still, I applaud your effort to not only suggest a useful feature but to
> also back it up with code. The opinion of someone who write code always
> carries more weight than the opinion of folks like me who just cheer
> from the sidelines :-)
Thanks... the opinion of Tcl/Tk-guru like you is highly valuated !
Koen
Koen Danckaert
>
> I'll also mention that
> 1) I never really needed this before,
> 2) if it exists I can maybe see using it sometimes,
> 3) it would be very very very bad if the autoname returned an
> existing widget.
>
> I know it make the implementation easier but that is a nightmare bug
> waiting to bite someone.
> I add some widget somwhere and I have to be careful that nowhere else is
> the autoname feature
> being used, and/or if I want to use autoname I have to be careful no
> other widget is geing
> named that way and in both cases I have to no the inner implementation
> details of the autoname
> functionality itself. if it is autoname - i should NOT care if it is a
> number or a random
> string. it seems it wouldn't be that hard in the implementation to add a
> check for existing widget
> and keep incrementing until an unused one was found.
I've updated the TIP and its implementation. It's now guaranteed that no existing widget name is returned.
Koen
Alexandre Ferrieux
wrote:
> Alexandre Ferrieux <alexandre.ferri...@gmail.com> wrote:
> > I'd cross the canyon and admit I'm against this. The whole thing can
> > be simply approximated in pure Tcl by renaming the proposed 'autoname'
> > to '%':
> > set frame [frame [%] ...]
>
> That's no solution, because you still have to pass through
> the new frame's parent, and you surely wouldn't suggest to
> creat such a %-procedure for each and every parent :-)
Oh, you're right. Then what about:
set frame [autoname frame .a.b ...]
where autoname is doable in pure Tcl:
proc autoname {creator parent args} {
(generate proper $child given $parent)
eval [list creator $child] args
}
-Alex
Alexandre Ferrieux
wrote:
>
> proc autoname {creator parent args} {
> (generate proper $child given $parent)
> eval [list creator $child] args
> }
Sorry, two dollars lost here:
proc autoname {creator parent args} {
(generate proper $child given $parent)
eval [list $creator $child] $args
}
-Alex
Alexandre Ferrieux
>
> Still, I applaud your effort to not only suggest a useful feature but to
> also back it up with code. The opinion of someone who write code always
> carries more weight than the opinion of folks like me who just cheer
> from the sidelines :-)
Sure, contributing the code is a bonus; it may even be a necessary
condition for inclusion when resources are tight (they are *always*
tight, I know ;-).
However, I hope it is not a *sufficient* condition... Every new
feature adds to the overall code size, possible interdependencies,
lack of coverage of the test suite, etc. And even to the simple task
of "describing" what Tcl (or Tk) does (think about the alphabetic
index of Perl books where the interesting parts look like "_" -- would
you like to hear say that Tcl is full of peculiarities just like
Perl ?)
So not every new feature should be included just because it is (1)
desired by a few and (2) implemented. Otherwise I'd TIP for a
[multiply_by_thirteen] (I believe I'd be able to get it right ;-).
-Alex
davidn...@gmail.com
This all boils down to Tcl not having a good system for keeping track
of references to complex resources. So what happens is that a string
is created, which points to a struct, via a hash table.
Everything is a string - except when it isn't and you have to manage
resources by hand.
Donal K. Fellows
> proc autoname {creator parent args} {
> (generate proper $child given $parent)
> }
Remember, this is in the post-8.5 world:
proc autoname {creator parent args} {
(generate proper $child given $parent)
$creator $child {*}$args
}
Donal.
Andreas Leitgeb
as resonable ...
then:
Bruce Hartweg <doNO...@nowhere.com> wrote:
> I know it make the implementation easier but that is a nightmare bug
> waiting to bite someone. I add some widget somwhere and I have to be
> careful that nowhere else is the autoname feature being used, and/or
I don't quite follow that logic...
you talk about different packages creating widgets into the same
pre-existing frame/toplevel, which only *after* this autonaming
feature is supposed to run into the risk of collision???
Really, I don't get it.
I agree, that automatic avoiding of collisions with already
existing sibling-widgets is not exactly bad, but neither is it
strictly necessary, nor is it sufficient to avoid clashes.
(and even less does the continued lack of autonaming protect
us from such problems)
What if I create a statically-named widget .42 *after*
some package has already created .1 up to .50 ?? what if
some package creates .label, and I've named mine just the same?)
Even without this explicit collision-detection, autonaming would
surely reduce probability of collisions, and even more so if it is
used well, that is: not just with %, but with prefix%. Since the
counter is central in Tk, even same prefixes wouldn't hurt.
Uwe Klein
I am not dependent on the mailing list for this
as
Tipper the Reaper, my homegrown gnome
does this nightly for me.
( Notice that the tcl-core references are no longer sourceforge based
as I seem unable to extract a usefull URL from the sourceforge list archives. )
The TclUrl was already finished and sent on sunday night (TZ=MST)
As I am at a customer site Mo .. Thu and a bit cut off there
for the weeks to come.
The sunday night deadline will thus stay for the duration.
uwe
keithv
wrote:
> A correction: there has been a new TIP published (#306: Auto-Naming
> Widgets) but the publication is stuck because of a mailing list outage
> at SourceForge.
My worry about this tip is that it makes yet another
character magical, and thus making future syntax
enhancements more difficult.
One of the big hurdles for the new {*} feature was
trying to find some syntax that wasn't already taken.
As just one possible example, I could envision a
time when "%" would be used, as a shorthand
for lindex, e.g %myList{3}. This tip would make this
impossible.
Just a concern,
Keith
Bryan Oakley
Why would it make it impossible? The auto-naming only applies to widgets
and would not be used in any other context (if I understand the TIP).
In thinking about this more (but not much more...), maybe a better
solution is to not use a special character and instead change the
behavior of the widget commands.
For example, give each widget a "-parent" option that defines its parent
widget. Then, allow the widget command to be called without an explicit
widget path (or maybe a null path?), in which case it creates an
auto-named child of the parent.
For example:
# create a container
frame .f
# create an auto-named button in .f
set b [button -parent .f -borderwidth 2 ...]
The use of -parent and an explicit pathname would be mutually exclusive.
That is, you can do "button .b" or "button -parent .f" but not "button
.b -parent .f". Though, come to think of it, "button .b -parent .f"
could just as easily create a widget named ".f.b".
... just offering some food for thought.
Ramon Ribó
Hello,
Another detail to take into consideration is that some existing TCL
packages
already use something similar.
For example, it is possible in snit:
set d [dog obj_%AUTO%]
suffix %AUTO% is longer to write than '%' but should avoid other type
of difficulties.
En Thu, 14 Jun 2007 19:01:20 +0200, Bryan Oakley
<oak...@bardo.clearlight.com> escribió:
--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ram...@compassis.com
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 l/
Alexandre Ferrieux
> set b [button -parent .f -borderwidth 2 ...]
If you blend this with my external-autoname proposal a few millimeters
higher up in this thread, you can even do:
set b [newchildof .f button -borderwidth 2 ...]
<TIP-kill>
Needless to say, [newchildof] can be written in pure Tcl (and has been
able to since 7.x...).
</TIP-kill>
-Alex
Alexandre Ferrieux
Oh sure -- I keep forgetting :-}
However, please bear in mind that I'm proposing something *without* a
patch: a pure-Tcl solution that whoever's ineterested can apply to any
of today's deployed distribs. I have 8.3.5's by dozens.
-Alex
Alexandre Ferrieux
wrote:
>
> Needless to say, [newchildof] can be written in pure Tcl (and has been
> able to since 7.x...).
*and* it also works with megawidgets without effort.
-Alex
Koen Danckaert
> keithv wrote:
>> My worry about this tip is that it makes yet another
>> character magical, and thus making future syntax
>> enhancements more difficult.
>>
>> time when "%" would be used, as a shorthand
>> for lindex, e.g %myList{3}. This tip would make this
>> impossible.
>>
>
> Why would it make it impossible? The auto-naming only applies to widgets
> and would not be used in any other context (if I understand the TIP).
Indeed, it would not be used in any other context.
Note that "%" character in Tcl is already associated with the notion of substitution, e.g. in bindings and in string formatting. This would not conflict with its use in this TIP, because its not followed by another character here.
On the other hand, using it as a shorthand for lindex, would more likely lead to conflicts.
> In thinking about this more (but not much more...), maybe a better
> solution is to not use a special character and instead change the
> behavior of the widget commands.
>
> For example, give each widget a "-parent" option that defines its parent
> widget. Then, allow the widget command to be called without an explicit
> widget path (or maybe a null path?), in which case it creates an
> auto-named child of the parent.
>
> For example:
>
> # create a container
> frame .f
>
> # create an auto-named button in .f
> set b [button -parent .f -borderwidth 2 ...]
>
Then there are two different syntaxes for creating widgets. I don't think this would be good for code readability. For example, when mixing normal and auto-naming, the proposal of the TIP would give code like:
set top [frame $f.%]
set main [frame $f.main]
set bottom [frame $f.%]
Also, when using -parent as an option, should it appear in the configure list of the widget ([$b configure -parent])? Also for widgets created with a manual name?
I still think the syntax proposed in the TIP is the most consistent and the most convenient.
Koen
Bryan Oakley
> Bryan Oakley wrote:
>> For example:
>>
>> # create a container
>> frame .f
>>
>> # create an auto-named button in .f
>> set b [button -parent .f -borderwidth 2 ...]
>>
> Also, when using -parent as an option, should it appear in the configure
> list of the widget ([$b configure -parent])? Also for widgets created
> with a manual name?
Yes, I would expect -parent to work like any other option in that it
would return the value that was set. If you don't set -parent, it would
return an empty string.