toplevel .test ; wm frame .test

I assume that the problem is due to the fact that the wm frame command is
executed before .test is ever mapped. It looks like a hole in the robustness
of tk and the usefulness of the wm frame command.

Has a patch or workaround been posted? I don't want to do an update, because
I want my toplevel widget's children to have a chance to create themselves
before the toplevel gets mapped. I suppose I could do the wm frame command
in a binding for the <Map> event on my toplevel, but then I have to filter
out all of the <Map> events for its subwidgets. Any ideas on how to get the
window handle for a toplevel safely?

you will need later to wm deiconify .test

'hope it is what you asked for,
Pascal

That might be sufficient. But then again, if you really want the
identifier of the window manager window and not the toplevel itself, you
might have to wait until the window is actually drawn on the screen
since that window manager window may not exist until it is really, truly
needed.

Put another way, here's the workaround for your test above:

    toplevel .test; wm withdraw .test; update idletasks; wm frame .test

At least, for my installation (8.0.3 on NT) it works fine and returns
something that I can only assume is correct.

The solution to your other problem (binding to <Map>)... to keep the
binding from firing on all the children, attach the binding to a
bindtag, and attach the bindtag only to your toplevel.

--
Bryan Oakley
ChannelPoint, Inc.

Cameron Laird           http://starbase.neosoft.com/~claird/home.html

What if we created comp.lang.tcl.answers, a moderated group,
specifically for the purpose of creating a "living FAQ". When someone
sees a question they think they can give a definitive answer to they can
crosspost to this group. If we establish some standards such as the way
the subject is formatted and maybe some special key words and other
fluff, this could instantly become a living document of questions and
answers. Being moderated, the S/N ration could, in theory, be 100%.

We could even seed this newsgroup with our existing FAQs, reformatted
slightly to whatever format we choose, for easy searching. With just a
little extra work we could also create a weekly or monthly digest of
postings for those who don't want to take the time to read c.l.t but
want all the Good Stuff. This would sort-of replace Tcl-URL! and spread
the burden out a bit.

A second idea is simply a web page (or tcl client app) for submitting
items to the FAQ in an automated fashion. Again, when someone sees a
question they are interested in fully answering, instead of just
replying in c.l.t they could fire up the web page or client, fill in all
the blanks, and press a magic button. The article would get posted to
c.l.t and optionally emailed to the original question-asker, and the
question and answer could be automatically added to an official FAQ.

With either of those scenarios, here's another suggestion that can work
hand-in hand: a tcl FAQ browser. Making the assumption that the tcl
FAQ(s) are at a known web location and in a known format, we could
easily write a simple tcl application that makes it really, really easy
to browse the FAQ, search on keywords, even launch man pages. Then, when
a question comes up in the newsgroup we can say "download the FAQ
browser!". Not only that, we can set up the browser as a web "helper
app" so we could provide a link they could click on (assuming they've
already downloaded the faq browser but were too lazy to fire it up).

I would be willing to write the latter, though I don't have any
experience doing http/html stuff in tcl (but I can read the FAQ to find
out how :-).

(all cylinders are firing now! chug, chug, chug!)

Not only could the faq browser let one browse the faq, we could also
have a button that formulates a standard "it's in the faq" reply. When
we read the newsgroup and see a newbie asking an age-old question, we
fire up the browser, hunt down the specific question out of courtesy,
press a button, paste the contents of the clipboard (conveniently
created by our faq browser) into our news agent, and we're done. No more
typing. Imagine that -- spend scores of hours writing an application so
that it saves me a few seconds of typing! :-)

FWIW, the idea for the FAQ browser stems from the fact I suspect lots of
people don't read them just because they are a pain to track down. And
even when we find the faq we are looking for we don't bookmark it or
bury the bookmark so deep we forget its there. And then we are sort of
limited to plain text searches. That, or we go to DejaNews and have to
find the needle in the haystack. With a client program loaded, I
theorize it might be more likely that people will actually read the faq.

:This got me thinking (I hate it when that happens!), and I have a couple

I hope that we get _more_ readers thinking and then writing...

:What if we created comp.lang.tcl.answers, a moderated group,
:specifically for the purpose of creating a "living FAQ". When someone
:sees a question they think they can give a definitive answer to they can
:crosspost to this group. If we establish some standards such as the way
:the subject is formatted and maybe some special key words and other
:fluff, this could instantly become a living document of questions and
:answers. Being moderated, the S/N ration could, in theory, be 100%.

Please don't take the following questions as if I were opposed to your
suggestion.  If asked face to face, my voice and body language would
be implying an interest to know more...

What is the purpose of using a newsgroup for this?  I know that a number
of people I talked to this past week have lost usenet access over the past
year.  Others indicated they had no access to begin with, or had no
time/interest in trying to track a newsgroup.  In my case, we keep at
most 5 days of news - no much 'living' in that time frame.

Would perhaps some sort of WWW based forum, where articles don't 'age'
off be better?  I used to play a bit with something called WebThing, which
was a combo forum and faq database hybrid.  Perhaps something could be
written up in tcl.

:A second idea is simply a web page (or tcl client app) for submitting
:items to the FAQ in an automated fashion. Again, when someone sees a
:question they are interested in fully answering, instead of just
:replying in c.l.t they could fire up the web page or client, fill in all
:the blanks, and press a magic button. The article would get posted to
:c.l.t and optionally emailed to the original question-asker, and the
:question and answer could be automatically added to an official FAQ.

This is a very interesting idea.  I have tried to advocate in the past
that if people would Cc me in announcements, etc. that it would make
it easier for me to get my updates into the FAQ.  Others do their
FAQs differently.  That's the biggest problem - each person has different
criteria.

:With either of those scenarios, here's another suggestion that can work
:hand-in hand: a tcl FAQ browser. Making the assumption that the tcl
:FAQ(s) are at a known web location and in a known format, we could
:easily write a simple tcl application that makes it really, really easy
:to browse the FAQ, search on keywords, even launch man pages. Then, when
:a question comes up in the newsgroup we can say "download the FAQ
:browser!". Not only that, we can set up the browser as a web "helper
:app" so we could provide a link they could click on (assuming they've
:already downloaded the faq browser but were too lazy to fire it up).
:
:I would be willing to write the latter, though I don't have any
:experience doing http/html stuff in tcl (but I can read the FAQ to find
:out how :-).

This sounds like a good idea. If you decide you want to follow up on this,
drop me _email_ about the topic and I will try to allocate a fixed amount
of time a week for brainstorming, etc.

:press a button, paste the contents of the clipboard (conveniently
:created by our faq browser) into our news agent, and we're done. No more
:typing. Imagine that -- spend scores of hours writing an application so
:that it saves me a few seconds of typing! :-)

If you do this, I myself would love it if you formated the answers in the
'tutorial' notation.  That is, show how you found the answer - so the
receiver perhaps will take the hint and try that would him/herself.

:FWIW, the idea for the FAQ browser stems from the fact I suspect lots of
:people don't read them just because they are a pain to track down. And

I want to continue to encourage people to send me URLs for FAQs that I
don't have listed at <URL:http://www.purl.org/NET/Tcl-FAQ/>.  That's
the primary purpose for that page...

:bury the bookmark so deep we forget its there. And then we are sort of
:limited to plain text searches. That, or we go to DejaNews and have to

yes - and the plain text searches are, in the most part, at a VERY crude
level - unfortunately.

:find the needle in the haystack. With a client program loaded, I
:theorize it might be more likely that people will actually read the faq.

Perhaps it could be made a tclet or standalone ...

--

<*> O- <URL:http://www.purl.org/NET/lvirden/> |     only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

:Should this be in Jeffrey's FAQ <URL:http://
:oprs.mchh.siemens.de/tcl/faqs/tk/>?  OK; it's

Note that Jeffrey has less connectivity to clt these days  - as
people find solutions to what appear to be frequently asked questions,
be sure to mail him (or the other FAQ maintainers _directly_ to
make sure we see the note.

:if Jeffrey says so.  I'm really asking a more
:general question:  what's a good (even best!)
:way to organize expertise as Bryan exemplifies

Michael Scwartz asked this very thing at the Tcl internet resources BoF.
We didn't really come up with a very good answer.  I don't like the
'use the DejaNews' solution.  It's too tough to search dejanews for
specific code sequences.

:the Tk FAQ?  The FMM?  Should there be a tutor-
:ial on binding, or perhaps just on bindtags?

I like to see white papers written myself...

:Should it be one of the examples for Chris
:Nelson's project to upgrade documentation?  Can

And please readers - contact Chris to volunteer to help if
you can make the time and contribute to the cause.

:quate?  Should we hold a spontaneous BoF out
:here in the hall, while most of the group is
:listening to the WIPs?  Speaking of which, the

No - but for instance there were _4_ evenings without anything related
to the conference (Sunday after registration, Monday and Tuesday after
tutorials, and Friday).  Seems like there is a lot of room for more
help sessions.

:Conference has been going on for over twenty-
:four hours, and I haven't seen any realtime,
:online reports yet.  How's connectivity in San
:Diego?

I thought the first few days I was going to die without net access.
I seem to recall first hearing of the connectivity on Wednesday.
It required a box with ether, and I had no box at all.

--

<*> O- <URL:http://www.purl.org/NET/lvirden/> |     only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

   No - but for instance there were _4_ evenings without anything related
   to the conference (Sunday after registration, Monday and Tuesday after
   tutorials, and Friday).  Seems like there is a lot of room for more
   help sessions.

USENIX had advised against putting any activities on those nights,
because typically only a small percentage of the total attendees are
present for tutorials.  What actually happened was that we got a very
high percentage (in fact, well above any other USENIX event) probably
due to the strong tutorial program.  Initial discussion is to repeat
it, so we will have BOFs on Monday and Tuesday next year.

   :Conference has been going on for over twenty-
   :four hours, and I haven't seen any realtime,
   :online reports yet.  How's connectivity in San
   :Diego?

   I thought the first few days I was going to die without net access.
   I seem to recall first hearing of the connectivity on Wednesday.
   It required a box with ether, and I had no box at all.

Days 1 and 2 were tutorials only - so there wasn't really anything to
report.

This was just as well since the net only started working Wednesday
morning.  We actually had access to the line on Monday but USENIX had
only paid for the line beginning on Wednesday so we can use that as an
excuse.  In reality, we also had one other problem: the ISP gave us
incorrect routing information.

Once we overcame that, the network was fine and we never even came
close to running out of capacity.

I agree that it would have been nice to have had public boxes.  We
solicited for volunteer hardware (or cash) but no one offered so there
wasn't much we could do.

As an aside, last year's network was configured the same way (BYOBox)
and no one complained about it last year.  I didn't bring a box either
but there seemed to be a number of people willing to lend me their box
(same thing last year), which is why I didn't even bother to bring a
box this year.

Don

Those who haven't been before should be warned;
Tcl Conferences are FAR more participatory than
even some other Usenix events (which are invari-
ably way ahead of the mass-market "conventions").
                        .
                        .
                        .

Friends and relatives are both policemen and
ISPers, so I write this without prejudice.
                        .
                        .
                        .

Cameron Laird           http://starbase.neosoft.com/~claird/home.html

Bottom line for me is, we need some sort of automated (and at least
semi-moderated) way to add questions and answers to a FAQ.

--
Bryan Oakley
ChannelPoint, Inc.