Why is it called TclMacBag?
It's a bag full of Tcl widgets for Mac.
Why a bag in particular? I was most likely thinking of Felix the Cat's magic bag of tricks ;-). Felix the Cat, created by Pat Sullivan in the 1920s, is another Aussie invention :-).
Which libraries are needed to get access to the different button styles?
Tkimg, Tkimggif and Tkimgpng (all are binary components of the Img package), Snit and Tile.
Can I include text in my buttons?
The -text option is supported in Stylebuttons and Viewbuttons in v0.09 and up.
I get the error 'Unknown display passed to Tk_PreserveColormap'
This is a Tk bug with ID 1785511 at Sourceforge (unknown display passed to
It's believed that work-arounds were put in place for this in version 0.05. If you run into this problem, please report it.
Why does TclMacBag use images to control style/view-button appearance, rather than hook directly into Carbon or Cocoa?
There are two answers to this. Firstly, I'm a Tcl guy and not a C/C++ Mac libraries specialist. I've also seen the C/C++ Mac libraries specialists get bogged down,
presumably because the task is a hard one. Secondly, the method I've used means it will be extremely easy to adapt when Apple brings in its next whim induced fashion change to its
The disadvantage to this is a small speed sacrifice and a little extra RAM to store the images. It's a price I know I'm happy to pay,
for being able to use more native looking Mac widgets sooner rather than later.
Where are the Mac Widgets™? I only see UI controls.
In the Tcl/Tk world, user interface controls are called widgets. Tcl/Tk has been around a lot longer than the little Mac scripts Apple calls widgets.
What's up with the 'package require Img'?
From 0.13, TclMacBag tests to see if the binary libraries Tkimggif and Tkimgpng are loaded. If not, it will 'package require Img'.
This allow software developers to manually load the individual library binaries rather than using package management.
In practice, Img is an all-or-nothing package.
Even 'package require img::png' and 'package require img::gif' drags in every other supported format, which adds over 1.2 Meg
of binary libraries. That's rather bloaty for starpack distributions. TclMacBag only needs PNG and GIF.
The scrolledframe has some issues...
You noticed too, huh? Known issues include:
There was a documented feature that disappeared...
Occasionally, a documented feature (marked as being likely available in a future release) doesn't end up eventuating. Reasons may include:
(1) lack of time, (2) lack of need, (3) finding something serviceable elsewhere, (4) finding the results don't work as hoped. These things
happen. Ideally, they'd only be published when they're complete, but, I find it personally useful to write a general spec and work to it.
What is the future of this package?
There seems to be a fair bit of support for adding TclMacBag to Tklib, which would add it to ActiveState's Teapot repository
and to many major Tcl distributions.
I'm pleased with the enthusiasm but don't feel the code is quite bullet-proof enough or complete yet. A general roadmap would be:
I've always seen this package as a bridge: it's quite possible (even likely and desirable) that either (a) Tile's improvements over time will render
many of TclMacBag's widgets redundant, or, (b) Tk's move to Cocoa on Mac will make many of TclMacBag's widgets redundant. It's another reason
why I'm hesitant to rush TclMacBag into mainstream use.
Why isn't my question isn't answered here?
It's early days and hasn't been asked yet. Or maybe the documentation's especially good :-).
Ask away using the contact form. If the contact form gets busy, I'll look at adding a forum of some kind.