From: Jim I. <ji...@ap...> - 2002-02-02 18:03:25
|
On 2/2/02 3:26 AM, "Ruediger Goetz" <rg...@r-...> wrote: > Hello, > > I recently was quiete busy with other projects, and hence didn't spend > much time with Tcl/Tk and tix. > > However, in order to check my preliminary tix-port I need run tixwish > from the Shell rather than from the finder (There is a demo script > which would make testing easy, but its written in a mixture of sh and > tixwish). Unfortunately, if I start tixwish from the shell no window > is opended, unless I cded to the path where the tixwish is located > (or copied or linked to (sym or hard)). Even worse If I start wish > in gdb wish a window is opend either, indepent of path I am on. > > Since my tixwish is only an extended wish my problem occurs in both. > And I tried to find out the difference by hacking printf's into the wish > code. Everything seem to be identical (as far as I can tell from my printfs). > The only difference is that the call of > ShowWindow(GetWindowFromPort(destPort)); > in line 171 of macosx/tkMacOSXSubwindows.c. > As far as I can tell destPort and GetWindowFromPort(destPort) have reasonable > values > in both cases. But since the Carbon structures WindowRef and CGrafPort > are not documented in the Developer tools documentation. I can"t figure out, > whether > there is an import difference in there value. > So this would be a task for someone more experienced wth Carbon (This port > ist my first contact to the Carbon API). Anyone, Or at least any hints? > I haven't figured out a good workaround for this yet, but you have to have the app in an App bundle with the appropriate support files for it to launch properly. There is some other way to invoke the proper voodoo - I have seen an app or two that do, but I don't know what it is. If you are using PB to build Tix, then just make an App target for the executable. If you are using configure/make, the easiest way to do this is to make a PB project with two targets, one a "legacy makefile target" that builds your TixWish from the configure/make, and one that makes the App, and has a "copy files" build phase that copies the executable into Contents/MacOS in the App package... > > BTW: Another quirk (of less importance) came to my mind. If I double click on > a > tcl-/tk-script, I can make wish start, but loading the script and running it. > It would be nice to have tcl/tk-scripts uasabel as normal programs, just be > started > by double clicking. The way to do this (though it was broken in the first binary release) is to clone the Wish.app, and put a script in the Resources/Scripts folder called AppMain.tcl. That is your startup script. If you define a proc called tkOpenDocument, then this will get the open AppleEvent from double-clicking on a script document (though I don't think that I have made a document type on the X side yet - though this would be trivial to do)... But, we didn't make double-clicking a script launch the App because the Mac OS behavior is that the second App document opened loads the document into the running App. This would not be what you wanted, since the two scripts would be launched into the same interpreter, you could get collision of globals, etc... I thought for a while about coming up with some clever way to farm the scripts off to separate interpreters, but this seemed to be just asking for trouble... The app way works much better for real Tcl applets, the Wish.app is quite small, and this way you can customize the icon, etc... Hope this helps, Jim > > > BTW: I checkout the current version from CVS today. Hence the mentiond bug are > not due > to old TCl/Tk versions, > > Yours > > R"udiger > > > -- ++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++= Jim Ingham ji...@ap... Developer Tools - gdb |