[MACTCL] Re: tcl_platofrm & MacOSX

[Jim I. <ji...@ap...>]

Daniel,

Our plan was to add:

tcl_platform(windowingsystem) = aqua

to the tcl_platform array for Aqua Tk.  Similarly, a version of Tk that 
was built on Mac OS X but linked to the X11 libraries (since you can 
actually have both on the same MacOS X box) will have:

tcl_platform(windowingsystem) = X11

The final form of this is not set, since it is a change to all the 
platforms, so we may end up changing the name of the variable to suit 
everyone's tastes when we go to submit all this stuff.

Turns out that if you don't do this, there are a few places in the Tk 
tcl library code (like tk_popup) that will work wrong on Mac OS X, since 
they key off of tcl_platform(platform)==unix.  We had to fix those, and 
the only way to do this was to have Tk provide an indication of which 
version of the code it was running.

So if you are doing Tk stuff, DON'T key off of either the platform or 
the os fields, since they won't actually tell you whether you are using 
the X11 Tk code, or the Aqua.  But for Tcl code you should continue to 
use unix and Darwin, we WON'T change the Tcl only values of this array.

The only problem here how to identify the presence of the MacOS specific 
code in Tcl, like the resource manager code.  I think it would also be 
really nice to add some interface to the NSFindStuffInBundles API's, 
since this would be very useful to reimplement the D&D Tclets stuff for 
MacOS X.  We can't use Darwin for this, since any of this that depends 
on Foundation or Carbon won't be present on Darwin, only on true MacOS 
X...

I think that for the Mac code in Tcl I am going to solve this 
differently, moving all that code (like the resource manager stuff) out 
to a separate package.  This is because I don't want to have to link the 
base Tcl library to Carbon.  I would be happier with doing a package 
require for this.  So you can test for whether you have these 
capabilities by doing:

if {[catch {package require MacTcl}]} {
...
}

or something like that.  I haven't done this yet, but it should not be 
too hard to separate out most of this stuff.

Jim

On Thursday, September 13, 2001, at 10:10  PM, Daniel A. Steffen wrote:

> [[ This message was both posted and mailed: see
>    the "To," "Cc," and "Newsgroups" headers for details. ]]
>
> In article <3b9f5eb9$0$42882$8e9...@ne...>, Ryan Casey
> <sc...@ho...> wrote:
>
>> Below I have included the tcl_platforms that I am currently 
>> programming to.
>> (Actually, Linux too, but I don't have a test machine to get the 
>> info.)  My
>> concern is with MacOS X.  Is the platform=unix, os=Darwin canonical.  
>> IOW,
>> can I be sure this is how Tcl is always going to report it?
>
> yes that's pretty much guaranteed, as tcl on unices simply reports the
> result of uname() in tcl_platform(os) and that's VERY unlikely to
> change on OS X as a lot of things depend on this being 'Darwin'.
>
>> It makes my
>> platform-specific switching structures a little more complex and
>> unintuitive, considering I load Mac stuff two places (first if
>> platform=macintosh, then if platform=unix, os=Darwin).
>
> but that's a good thing, i.e. for a lot of code, tcl on darwin should
> not appear different from other unices, e.g. TclX works just fine
> essentially unchanged (minor changes required...)
> OTOH, if os==Darwin, you can assume that a lot of things that work on
> platform == macintosh will work as well, e.g. Tclapplescript (not just
> yet...), TclAE (done), hopefully the 'resource' command and other mac
> specific commands (beep) in the near future, as well as other
> carbonizable extensions (QuickTimeTcl comes to mind, maybe Snack?)
>
> so if you need to know, you can find out if you're running under OSX
> but most code running on other unices will not need/want to know and
> will still run just fine.
>
> in most cases you may actually want to be careful about assuming that
> os==Darwin is equivalent to platform==macintosh, esp. if you make
> assumptions about macintosh specific behaviour, for instance w.r.t
> paths (path separator is '/' not ':', no volumes etc)
>
> Things may change a bit on Tk, considering there will be two
> possibilities for Tk, Tk on Xwindows and TkAqua... not sure how this
> will be handled/reported yet; Jim?
>
> Cheers
>
> Daniel
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb