[MACTCL] So many Tcl/Tk problems on the Mac...

[George@Orwellian.Org]

I'm really disappointed with this list.

I guess I'll unsubscribe in a few days. 

I'm working on a [paid] app for a record store,
and it's for the Mac (under MacOS 9.1.4). 

My expertise is Unix (Solaris). 

So I thought I might be able to get some help
when I run into problems. But no, I'm not even
getting a response, aside from one thing. And
that one thing was answered best by a Usenet
reply. 

 ---- 

The first coding problem I ask for feedback on
was a problem with "pack forget" not completely
unpacking a hierarchy, leaving a mess on the
screen. 

Brent Welch's book recommends that technique
for fast instantiation. 

Not a single comment, reply, or email on that. 

So I worked around it by not using it. 

I used two top level windows instead. 

 ---- 

The next problem I had I didn't post about. 

I couldn't get focus to _any_ field when the app
was first started. After a while I realized that
when the window first comes up, if I click on
the background desktop then click on my app's
window again, it had focus. Focus to the field
I had waited on (successfully) for visibility
then had issued a focus command for. 

So, the work-around was to issue a toplevel .zot
immediately followed by a destroy .zot. It worked. 

 ---- 

The third problem I posted about, and received
zilch comment on. Here is the post again: 

#    Subject: [MACTCL] Another problem on the Mac
#       Date: Sun, 17 Feb 2002 16:29:52 GMT
#       From: George@Orwellian.Org
#         To: tc...@li...
#
#    Hi. The last post I made was regarding "pack forget" not
#    working properly.
#
#    There was not a single reply, email or list.
#
#    Is this because it is on MacOS 9.1?
#
#    Clients are hard to come by, and the client is running 9.1,
#    and so am I. I don't plan on using MacOS X until a number
#    of releases in the future.
#
#    So I'd really appreciate it if someone would look at this bug.
#    The previous bug I worked around by not using "pack forget", and
#    using two top-level windows instead.
#
#     ----
#
#    This time, still under a fresh install of ActiveState 8.3.4,
#    the menubutton is flaky.
#
#    Out of ten times clicking on it, either holding the mouse button
#    down, or releasing it, the pop-up menu appears then <POOF> it's gone.
#
#    I've isolated it down to a very few lines of code, enclosed.
#
#    Please, someone tell me if this problem happens for you,
#    and what might be done about it.
#
#    I source the file to execute it under wish. (The entry box that
#    used variable ::lce to display the chosen menu entry is chopped
#    out too, to no avail.)
#
#     ----
#
#  wm geometry . 746x536+24+21
#
#  set ::Canvas2a        [frame .f]
#  set ::COUNTRY_menu    $::Canvas2a.mb
#  set ::COUNTRY_menu_mb $::COUNTRY_menu.mb
#
#  menubutton $::COUNTRY_menu -text Country -menu $::COUNTRY_menu_mb
#  set mb [menu $::COUNTRY_menu_mb -tearoff 0]
#
#  foreach {country value} {U.S.A. USA UK UK Canada Canada Japan Japan  \
#      Germany Germany E.E.C EEC Italy Italy Australia Australia  \
#      {New Zealand} {New Zealand} Mexico Mexico Brazil Brazil  \
#      {South America} {South America}}  {
#
#      $mb add radio -label $country ;# -variable ::lce  -value $value
#  }
#
#  pack $::COUNTRY_menu -side left  -fill x
#  pack $::Canvas2a -side top 

 ---- 

I have hacked out a work-around, after about 6 hours
of screwing around. 

This involved looking up the bindings for Menu and Menubutton,
retrieving and loading into my app the procs involved, hacking. 

This was the solution: 

proc tkMbEnter {w}  { 

   global tkPriv 

   if {[string compare $tkPriv(inMenubutton) ""]} {
       tkMbLeave $tkPriv(inMenubutton)
   }
   # Commenting out the following line was the solution:
   # set tkPriv(inMenubutton) $w
   if {[string compare [$w cget -state] "disabled"]} {
       $w configure -state active
   }
} 

Although the menu doesn't pop-up anymore when just clicking on it,
by clicking (without releasing) and moving the mouse down slightly,
the menu now appears consistently *without vanishing* before a
selection can be made. 

 ---- 

I can only imagine that many many more people who experience
these sort of problems on the Mac simply terminate their
use of Tcl/Tk without reporting the bugs, and this is a very
bad thing for Tcl/Tk and its claim of working cross-platform. 

It's not like the 'menu' widget is an obscure use of Tcl/Tk.