Re: [MACTCL] Carbon port

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

Mats,

>
>
> "Daniel A. Steffen" wrote:
>>
>> At 16:08 +0100 on 6/1/02, Mats Bengtsson wrote:
>>
>>> Do I need to make it a Mach-O, in that case I'm stuck since I'm 
>>> running
>>> CW Pro 6.2. I'll better get myself a sponsor for a X machine :-)
>>
>> for an extension yes you need MachO, no way around it. This is
>> because Tcl can't load CFM libraries currently, and it would be
>> hard/impossible to make that work IMHO.
>> Even for an application embedding Tcl it's almost impossible to use
>> CFM, I tried for a while, and it's just too hard... (the main problem
>> hard to work around was that function ptrs are very different in CFM
>> and MachO, and obviously you need to pass a lot of those to Tcl when
>> e.g. creating new commands)
>>
>
> Well, no reason to make it more complicated than it needs to be;
> With the right tool it's just to set a switch somewhere.

It is not that hard, but it is not just setting a switch.  You need to 
make a Mach-O to CFM shim that contains all the Tcl routines that you 
will be using, and link to that with your CFM plugin rather than to the 
Tcl library itself.  You also need to make a Mach-O UPP for any command 
callbacks that you use, and in your *_Init pass that rather than the 
actual implementation routines to Tcl_CreateObjCommand or whatever needs 
the callback.

I don't think that NSAddLibrary will load CFM fragments, either, though 
I may be wrong about this, so you would have to link to QuickTimeTcl 
explicitly, and call the (UPP version of) your init routine in a custom 
Tcl shell, or we would have to teach the load command to load CFM as 
well as Mach-O.  GIven that Apple is officially deprecating CFM, and 
that CW does produce Mach-O (though admittedly only in the Pro 7 
version), I don't want to spend any time supporting CFM in Tcl.

>>
>> Do you have your current carbonized sources available somewhere? I'd
>> be interested to take a look.
>>
>
> I've put it at 
> "http://hem.fyristorg.com/matben/download/QuickTimeTcl30b2.sit"
> It's organized in the standard way with a project folder inside the
> Build folder, and the source folder in the "Tcl/Tk folder".
> There are some "#ifdef __APPLE_CC__" switches, but I'm not sure
> all necessary headers are there. Building the Carbon target in
> the project with 8.3.4 gives only errors from the Tcl/Tk stuff,
> the QuickTimeTcl is clean. There is no hook into any event loop
> so movie controller will not work. The best to hope for is that
> you may do ".m play", but that's also uncertain. I've set
> Carbon timers to serv movies, but they don't generate the
> events needed for MCIsPlayerEvent, which is the core API, so I
> send nullEvents, since I haven't found any Apple docs or sample
> code on this.

Okay, I will get this and take a look this weekend.  Don't let this stop 
other folks, however, if you are interested.  In my experience, the 
QuickTimeTcl stuff is really fun to play around with.  QuickTime is very 
cool, and you get lots of return for your effort...

>
> On other thing: With Carbon I switched from the 
> GetStandardFilePreview (?)
> to NavigationLib for tk_getOpenFilePreview. May implementation for this
> is a stripped down version that doesn't accept any options.
> Perhaps a better way is to set this with some flag in NavDialogOptions
> in the core implementation of tk_getOpenFile. What do you think?

We can either add an option for the preview to tk_getOpenFile, which has 
the complication that we have to figure out, at least formally, how to 
do it for Windows & X as well.  Or we can generalize the middle level C 
API's in tkMacDialog.c to allow a preview option, and let you use those 
for your tk_getOpenFIlePreview command.  Since the latter would be a 
first step to a more general tk_getOpenFile, I think that is the better 
first step, what do you think.  If you want to poke around here, and 
work something up, that would be great!

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer