From Newsgroup: comp.lang.tcl
Luc <
luc@sep.invalid> wrote:
I know y'all gonna hate this question because I'm not showing much code,
but I am really more interested in concepts than code.
I made a package. It's supposed to be a megawidget. I haven't snitted it
yet. I can't snit it without understanding where I am supposed to go
with it. So here is the problem.
package require giggles
set of $::w.outerframe
frame $of -height 100
pack $of -fill both -expand 1
set gg $of.giggles
::giggles::giggles $gg -guifont "Arial 14" -geometry pack
pack $gg -fill both -expand 1
And it works. The prototype megawidget is inserted into my test parent application.
The problem is, commenting out the last 'pack' line makes no difference.
The megawidget still shows. (Also, funny that apparently it's redundant
but nothing clashes.) And of course that is not standard widget behavior.
Of course, I am packing everything in the megawidget. But if I don't,
then what? I can't just leave it hanging because if I do, then the
author of the parent widget will have to inspect the code of the
megawidget to figure out what he is supposed to pack to get it all
working which, again, is not standard widget behavior, it's actually
pretty stupid. I have to expose something. Something that will take
the 'pack' command from the parent application and make the entire megawidget come together, with all of its components.
How do I do that?
You have at least two choices:
1) You document "giggles" to require a user of "giggles" creates a
frame widget, and passes it into your "giggles" call, and you pack
everything into that frame. It looks, from the above code, like this
is the option you have chosen. But, this makes your megawidget
different from the Tk native widgets. You don't pass a "frame" to
"text" and have "text" build a "text widget" inside that frame.
2) You redesign "giggles" that it receives a "window path name" and it
creates a frame of that path name, and then packs everything that makes
up a "giggles" into that new frame, and then "giggles" returns the name
of that frame. This makes the megawidget more native like, because you
pass a name of a window that does not yet exist, and the "giggles" call creates a window of that name.
#2 is also the part where Snit helps, because left to its own devices,
that frame is just a regular Tk frame, and the only configure/cget
options it understands are those for frames. Snit lets you build this
as a window heirarchy (this will only look right with a monospaced
font, and note, I'm making this up):
gframe
|--label
|--inner frame
| |--text widget
| |--scrollbar
|--label
What Snit helps with is allowing "gframe" to be the name of your window (.something.something.gframe) and also a command for "driving" the
widget. Snit lets you redirect calls to .abc.gframe for say "insert"
to actually be delivered to the buried text widget
(.abc.gframe.inner frame.text widget)[1] so that users can call:
.abc.gframe insert end "This is extra text"
And have it really call:
.abc.gframe.inner frame.text widget insert end "This is extra text"
Without you having to manually do the command renamings necessary to
make that magic happen.
[1] Yes, Tk window paths can't have spaces in reality -- this is just
an explanation of one of the things Snit does for you if you use it to
build a megawidget.
--- Synchronet 3.20a-Linux NewsLink 1.114