Tcl/Tk and Mac OS X ?
Brian
using a unix-based kernel, would this mean the Mac version of Tcl/Tk will be
sharing "most" of it's code base with the Unix versions? Or is the plan to
work on a port after OS X is officially released? OR are there no plans to
port to OSX at this time at all?
Thanks!
Jeffrey Hobbs
that has a patch for getting Tcl to build on OS X. You can
find it in the deaj.com archives, or I can send you a copy.
At the moment, I don't have OS X, so I can't verify it. Also,
this is only for Tcl. I don't know (and don't know any that do
know) what the final plans are for OS X with respect to the
GUI toolkit and such. I don't know it the Toolbox will be the
standard any more.
--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.
Scott Redman
(or re-porting) Tk to MacOS X.
It turns out that MacOS X is really NextStep OS with
a Mac UI. It does not have an X Server, so the Tk
code will need to be rewritten or borrowed from the
current MacOS port. The MacOS X kernel is basically
Unix, and the Tcl unix code works fine without too
many changes (I think all of the changes were for
configure/makefile support). This is a *huge* leap
forward for Mac and the Tcl port for the Mac.
-- Scott
Brian
Do you know the effort that would be involved in porting the Tk GUI toolkit
to Mac OS X?
Thanks!
Scott Redman <red...@scriptics.com> wrote in message
news:3839B7B6...@scriptics.com...
James Ingham
> Last I heard, there are some people interested in porting
> (or re-porting) Tk to MacOS X.
I have been contacted by a number of people who are interested in
whether I or someone else was going to port MacTk to MacOS X. I have
NOT been contacted by anyone who was interested in trying themselves
:-(
This is something I had hoped to do this fall, but all my spare time
is being eaten up by my day job right now, so I probably won't get to
look at it till sometime next year. However, I will be glad to help
out with pointers for anyone who does have some spare time.
Here is a brief summary of the situation, for those interested. This
has been discussed before, so if you want more info, look at
DejaNews...
First of all, what Scott said about Tcl is pretty close to right.
There were changes for dynamic linking, as well as the Makefile
changes, since this is done very differently on NextStep than on other
Unixes. There is also a notion of "packages" which is very like the
resource fork of MacOS, which will be a part of MacOS X when it comes
out. We should probably cook up something to deal with this. But
Tcl will be MUCH easier to support on MacOS X than on Unix, as we can
share most of the Unix efforts.
Tk on MacOS X will still be a separate port. MacOS X, as it turns
out, has a pretty complete implementation of the MacOS Toolbox as one
of the base libraries in the OS (called the Carbon libraries). They
left out all the really unsafe things (like mucking around with the
global window list), but either implemented or alternate methods for
all the standard Toolbox functions. So we should be able to use Carbon
to port the Tk code from MacOS to MacOS X. This will make the port a
LOT easier, though I imagine that there is still a fair bit of work to
do...
Jim
>
> It turns out that MacOS X is really NextStep OS with
> a Mac UI. It does not have an X Server, so the Tk
> code will need to be rewritten or borrowed from the
> current MacOS port. The MacOS X kernel is basically
> Unix, and the Tcl unix code works fine without too
> many changes (I think all of the changes were for
> configure/makefile support). This is a *huge* leap
> forward for Mac and the Tcl port for the Mac.
>
> -- Scott
>
>
--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions Inc.
James Ingham
> Jim Ingham, if you're monitoring this thread.... :o)
> Do you know the effort that would be involved in porting the Tk GUI toolkit
> to Mac OS X?
> Thanks!
>
It is hard to estimate this, because it depends on how stable the
Carbon API's are and how many little semantic differences there are
between the MacOS and the MacOS X versions of the API. MacOS X itself
is a little flaky - though I haven't played with the DP2 which is
supposed to be better than DP1.
The only whole section you need to actually rewrite is all the file
dialog stuff, since you have to use Nav Services. I am almost done
with this, however - I have one bug that I introduced into the non-Nav
Services version to find. You will probably have to stop playing some
of the tricks we play when we double-buffer drawing the controls, and
use more of the Appearance Manager API's wherever you can. I have put
a bunch of this in, and have more bits on the garage floor now that I
could give to someone to clean up if they were starting to work on it.
I think it would also be a good idea NOT to try to maintain a common
source base for the Classic MacOS and the MacOS X version. If they
end up still being pretty common, we can merge them back together, but
it would be better at first to dup the files, and hack away freely.
This would also allow you to use Quartz for things like Canvas drawing
if that turns out to be easier... It might actually be worth the time
to redo some of the lower level XDraw calls this way, since the
graphics model of Quartz is supposed to be much richer than QuickDraw.
It would really help, as well, to have paid Apple's Developer program
fees, since I bet you will need to pester the DevSupport folks with
questions as you went along.
So, if you were working on it full time, I don't imagine it would take
more than three months to get version up and running, and then another
couple of months of field testing and bug fixing to make it really
useable. Of course, this assumes that you are already familiar with
the MacTk code, which is a bit of an odd beast. If you are not, give
yourself another month or so to grok it.
I was roughly guessing it would take me about six months of evenings and
weekends (of which I have none right now, sigh...) to get a first
working version, and then some long tail after that to fix all the
bugs & buglets.
Hope this helps,
Jim
> Scott Redman <red...@scriptics.com> wrote in message
> news:3839B7B6...@scriptics.com...
> > Last I heard, there are some people interested in porting
> > (or re-porting) Tk to MacOS X.
> >
> > It turns out that MacOS X is really NextStep OS with
> > a Mac UI. It does not have an X Server, so the Tk
> > code will need to be rewritten or borrowed from the
> > current MacOS port. The MacOS X kernel is basically
> > Unix, and the Tcl unix code works fine without too
> > many changes (I think all of the changes were for
> > configure/makefile support). This is a *huge* leap
> > forward for Mac and the Tcl port for the Mac.
> >
> > -- Scott
> >
> >
> > Jeffrey Hobbs wrote:
> > >
> > > We have an RFE from Wilfredo Sanchez (wsanchez at apple . com)
> > > that has a patch for getting Tcl to build on OS X. You can
> > > find it in the deaj.com archives, or I can send you a copy.
> > >
> > > At the moment, I don't have OS X, so I can't verify it. Also,
> > > this is only for Tcl. I don't know (and don't know any that do
> > > know) what the final plans are for OS X with respect to the
> > > GUI toolkit and such. I don't know it the Toolbox will be the
> > > standard any more.
> > >
> > > Brian wrote:
> > > >
> > > > Does anyone know if Tck/Tk is being ported to the new Mac OS X? As OS
> X is
> > > > using a unix-based kernel, would this mean the Mac version of Tcl/Tk
> will be
> > > > sharing "most" of it's code base with the Unix versions? Or is the
> plan to
> > > > work on a port after OS X is officially released? OR are there no
> plans to
> > > > port to OSX at this time at all?
> > > > Thanks!
> > >
> > > --
> > > Jeffrey Hobbs The Tcl Guy
> > > jeffrey.hobbs at scriptics.com Scriptics Corp.
>
>
--
Alexandre Ferrieux
>
> Here is a brief summary of the situation, for those interested.
Thanks Jim for this status report; it's very interesting !
> ... But
> Tcl will be MUCH easier to support on MacOS X than on Unix, as we can
> share most of the Unix efforts.
I guess what you mean is "easier to support on MacOS X than on older
MacOSes"...
> Tk on MacOS X will still be a separate port. MacOS X, as it turns
> out, has a pretty complete implementation of the MacOS Toolbox as one
> of the base libraries in the OS (called the Carbon libraries).
Wow. Funny how terminology changes: wasn't that called the Blue or
Yellow box yesterday ? :)
> They left out all the really unsafe things (like mucking around with
> the global window list), but either implemented or alternate methods
> for all the standard Toolbox functions.
So at last they have the guts to throw out the dark side of Holy
Backward Compatibility ! That's excellent news for Apple. Sounds like a
healthy decision.
-Alex
James Ingham
> >
> > Here is a brief summary of the situation, for those interested.
>
> Thanks Jim for this status report; it's very interesting !
>
> > ... But
> > Tcl will be MUCH easier to support on MacOS X than on Unix, as we can
> > share most of the Unix efforts.
>
> I guess what you mean is "easier to support on MacOS X than on older
> MacOSes"...
Yup...
>
> > Tk on MacOS X will still be a separate port. MacOS X, as it turns
> > out, has a pretty complete implementation of the MacOS Toolbox as one
> > of the base libraries in the OS (called the Carbon libraries).
>
> Wow. Funny how terminology changes: wasn't that called the Blue or
> Yellow box yesterday ? :)
This is different. There is still a Blue box, where you can run
un-recompiled MacOS applications. It has changed its name, of course,
to "Classic", and it now runs in the same window manager space as
MacOS X, and according to reports at ~85% of the speed of straight
MacOS on the same machine, which is actually pretty impressive...
Yellow Box is still there, it is the NextStep API's.
And then Carbon is a new feature, a way to port MacOS apps quickly to
MacOS X without having to run in the Classic mode, and thus getting
full memory protection, a modern, paged memory model, etc... However,
to use Carbon, you have to remove calls to the unsafe parts of the
MacOS Toolbox, and of course recompile...
>
> > They left out all the really unsafe things (like mucking around with
> > the global window list), but either implemented or alternate methods
> > for all the standard Toolbox functions.
>
> So at last they have the guts to throw out the dark side of Holy
> Backward Compatibility ! That's excellent news for Apple. Sounds like a
> healthy decision.
Well, they were always going to provide an application toolbox that
was incompatible with the old MacOS Toolbox in MacOS X. This decision
with Carbon is really to make one that still looks a lot like the old
Toolbox, but with the grotty bits cleaned up. The other incompatible
option is the Objective C based NeXTStep API's, which apparently not
all MacOS developer's showed enthusiasm for...
The NeXTStep API's will still be around, and will also be used in the
Java interface to the system, which seems to be pretty thorough-going,
for those Java enthusiasts out there.
And they are also augmenting the Toolbox with a new drawing API
(Quartz) and a whole new set of Text services, which are also
available in MacOS 9+, and which look really quite cool.
Jim
Alexandre Ferrieux
>
> There is still a Blue box, where you can run
> un-recompiled MacOS applications. It has changed its name, of course,
> to "Classic", and it now runs in the same window manager space as
> MacOS X, and according to reports at ~85% of the speed of straight
> MacOS on the same machine, which is actually pretty impressive...
>
> Yellow Box is still there, it is the NextStep API's.
>
> And then Carbon is a new feature, a way to port MacOS apps quickly to
> MacOS X without having to run in the Classic mode, and thus getting
> full memory protection, a modern, paged memory model, etc... However,
> to use Carbon, you have to remove calls to the unsafe parts of the
> MacOS Toolbox, and of course recompile...
Okay, so to take an obvious analogy,
Ol'good MacOS Windoze
MacOS X Linux
Classic Wine
Carbon Cygwin
YellowBox Xlib/posix calls
Is this description correct ?
-Alex
James Ingham
Close, but not quite. Carbon is not written ON TOP OF the normal
system API's (YellowBox, in this case), as Cygwin is. It is another
set alongside the YellowBox API's, so it does not - in theory - suffer
from the performance problems due to "impedance mismatches" between
the two API models.
Also, any comparision of MacOS to Windoze is highly insulting to the
former ;-).
Scott Redman
use a modified version of it to call the YellowBox directly.
-- Scott
James Ingham
No, or if there is, someone is not telling... Apparently, there was
an X-Server that you could buy for NextStep, and people compiled & ran
Tk under this, but that hardly counts as a port.
Jim
Alexandre Ferrieux
>
> Okay, so to take an obvious analogy,
>
> Ol'good MacOS Windoze
> MacOS X Linux
> Classic Wine
> Carbon Cygwin
> YellowBox Xlib/posix calls
>
> Is this description correct ?
Oops - 'Cygwin' above is a semantic slip: cygwin allows to compile
unix-sources on a Win platform, while in this slot of the table above, I
intended exactly the converse: Win32-API sources compiled on a unix. I
know such beasts exist, by the way. Would a kind soul refresh my memory
?
-Alex
Heribert Dahms
alexandre...@cnet.francetelecom.fr writes:
: Oops - 'Cygwin' above is a semantic slip: cygwin allows to compile
: unix-sources on a Win platform, while in this slot of the table above, I
: intended exactly the converse: Win32-API sources compiled on a unix. I
: know such beasts exist, by the way. Would a kind soul refresh my memory?
Wind/U from Bristol.
My collegues using Powerbuilder 6 under HP-UX suffer from this and
wait anxiously for PB7 native support of HP-UX 11 64bit...
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
Scott Redman
at Altera, on 32bit Solaris, HP, and AIX. I even got DCOM to
work on Solaris, MFC, etc. No 64bit support (yet?) or Linux
(announced, I think Q1-2000).
FYI, there are a lot of commercial companies using Tcl and MainWin
in their products, mostly EDA.
-- Scott
James Ingham
> Also MainWin from MainSoft (http://www.mainsoft.com). I used it
> at Altera, on 32bit Solaris, HP, and AIX. I even got DCOM to
> work on Solaris, MFC, etc. No 64bit support (yet?) or Linux
> (announced, I think Q1-2000).
>
> FYI, there are a lot of commercial companies using Tcl and MainWin
> in their products, mostly EDA.
>
Just to reiterate, Carbon is NOT like MainWin or Wind/U. It is not an
implementation of the Macintosh toolbox ON TOP OF the YellowBox
API's. Rather both are implemented on top of the Mach Kernel, and the
low-level drawing primatives.
BTW, seems like YellowBox is now being called Cocoa, not to be
confused with Cocoa, the EXCELLENT little children's programming
application produced by the Apple Technology Group a couple of years
ago, which is now morphed into Stagecast...