[MACTCL] Mac OS X native tk_messageBox

[Mats B. <ma...@pr...>]

Hi everyone,

As a warm up excercise on OSX I ported and rewrote my MovableAlerts
package. Shoot: "http://hem.fyristorg.com/matben/download/messagebox.gif"
Download binary and complete code:
"http://hem.fyristorg.com/matben/download/MovableAlerts.dmg"
This is a complete replacement for the tk_messageBox.
The new command is tk_newMessageBox (very original).

This project could perhaps serve as a template PB project for others.
A few problem I'd like some help with:

1)	Never managed to set the file for exported symbols.
Various complaints from nmedit.

2)	Seems not the resource for doing 'load' is the way to go here.
Am I correct? Is the usual pkgIndex.tcl file the only way? Liked
the single file extension on classic, but resource forks are not
recomended on OSX(?)

Could someone revise this project setup?

The previous MovableAlert never made it through the TIP process.
The complaint I got was on the 255 character limit in the message.
I could argue against this opinion but wont.
This limit is gone in this OSX version, so it seems to be fully
complaint with tk_messageBox as described in the docs.
So I wish someone revise the code and just plug it into the core.
There is an extra -finemessage option which perhaps needs to be
discussed. Also, the button texts are not automatically localized.
Try also the not much used option -parent toplevelPath. Surprise!
Very cool! Try it with a toplevel that is smaller than the dialog.
Perhaps a similar interpretation and implementation is 
possible for the tk_getOpenFile and tk_getSaveFile?

Best Wishes,   Mats

Attach some notes from Donal K. Fellows:

> I've been looking through the old TIPs and came across this one from
> way back:  http://purl.org/tcl/tip/25
> 
> As far as I can tell, it seems to be mainly requesting that the message
> box dialog on the Mac should follow the platform UI guidelines (which is
> a definite 'yes' surely) but there are some aspects that require further
> discussion:
> 
>  * message length truncation (a point previously raised by Vince Darley
>    if my records are correct.)  We should only tolerate this if the
>    platform forces us into it, particularly as the other platforms don't
>    have this limitation...
> 
>  * the -finemessage option (perhaps '-detail' would be a better name.)
>    It is really this that (IMO) forces this to be a TIP as opposed to
>    just something for the Mac maintainers, since it introduces an
>    incompatability between platforms.  Our alternatives are:
> 
>      o Introduce the incompatability; MacTcl already has a number of
>        features that make scripts written there less likely to be
>        portable, so one more won't hurt too much.
> 
>      o Add equivalent options on the other platforms.  This is easy on
>        UNIX but I've no idea about Windows (TIP#67's reasoning gives me
>        hope though...)
> 
>      o Grok the detail portion of the message from the overall -message
>        option by (in effect) splitting the string on the first newline
>        (for example.)
> 
> Any ideas?
> 
> Donal.