TclMacBag - Bag of Mac Widgets for Tcl/Tk
Frequently Asked Questions

HomeF.A.QChangelogLicenseAbout

Questions

  1. Why is it called TclMacBag?
  2. Which libraries are needed to get access to the different button styles?
  3. Can I include text in my buttons?
  4. I get the error 'Unknown display passed to Tk_PreserveColormap'
  5. Why does TclMacBag use images to control style/view-button appearance, rather than hook directly into Carbon or Cocoa?
  6. Where are the Mac Widgets™? I only see UI controls.
  7. What's up with the 'package require Img'?
  8. The scrolledframe has some issues...
  9. There was a documented feature that disappeared...
  10. What is the future of this package?
  11. Why isn't my question isn't answered here?

Answers

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 Tk_PreserveColormap).

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 widget appearance.

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:

Both of these issues are frankly fairly awful. I can't see a way around it which doesn't include rewriting it from scratch and using different component widgets to do it with.

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:

  1. Basic function "completeness" - Having all the widgets and options I want to see in it and working.
  2. Move to a public repository - Giving coders much better than I the opportunity to pore over it, fix their annoyances and make it better.
  3. Add to Tklib - Do what's necessary to make it widely available.

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.

© Peter Caffin, 2010-2017.