Menu
▾
▴
#179 loadable TkAqua
patches to core-8-4-branch and HEAD that enable [package
require Tk] for TkAqua:
All platform specific code from tkMacOSXAppInit.c is moved to
tkMacOSXInit.c and tkMacOSXAppInit.c is removed and replaced by
the generic unix/tkAppInit.c.
Almost all such startup code was interp specific and is moved into
the existing initialization code in TkpInit(). The only pre-interp-
initialization we need to do is setting up the Resources/Scripts/
AppMain.tcl startup file (if present), this code is moved to a new
TkMacOSXDefaultStartupScript() which is called from Tk_Main()
(the only change to generic code).
The main project change is addition of a pkgIndex.tcl script in
Tk.framework/Resources/Scripts, which enables [package require
Tk].
I've also added code to TkpInit() that checks if we are loaded into a
bundled executable; and if not, attempts to dynamically acquire the
undocumented CPSEnableForegroundOperation SPI and use it to
notify the window server that we are now a full GUI application (this
will not break if that SPI ever disappears or changes its name).
Even though we've previously discussed and rejected using CPS SPI,
I've lost my scruples on this after talking to the LaunchServices
engineers at WWDC (who said to go ahead and use the same
workaround that JAR launcher, SDL, wxPython etc all already use,
it's not likely to go away at this point and an official solution is not
in the pipeline). Just google for CPSEnableForegroundOperation to
see how widespread use of this SPI is... In any case, this code can
be disabled via #define if desired.
Of course it's still much preferred to use a bundled executable, as
you cannot get a dock icon, document bindings, a bundle id, etc
otherwise, also the aete resource for Wish is not available to an
unbundled executable (i.e. app cannot be targeted via AppleScript)
With all this, [package require Tk] now works from tclsh wrapped as
a bundled executable, and also unbundled if the above code is
enabled.
In particular, this also allows the Tcl::Tk perl module to properly
load TkAqua:
http://search.cpan.org/~vkon/Tcl/
http://search.cpan.org/~vkon/Tcl-Tk/
get release 0.84 which has my patches to build the Tcl module
against Tcl.framework, and configure the Tcl module with
perl Makefile.PL --tclconfig /Library/Frameworks/
Tcl.framework/tclConfig.sh --usestubs INSTALLSITEMAN3DIR=/usr/
local/man/man3
and the Tcl::Tk module with
perl Makefile.PL INSTALLSITEMAN3DIR=/usr/local/man/man3
both modules should pass all their 'make test's...
Jim, could you review this for checkin?
revised patch against core-8-4-branch
Logged In: YES
user_id=90580
patches updated with (hopefully) clearer comments & fixed typos
revised patch against HEAD
Logged In: YES
user_id=80530
Woohoo! Great work!
Now the niggling detail...
I haven't looked at this enough yet,
but my initial reaction is that I'd
be happier if this patch could use
Tcl_SetStartupScript() to take care
of its needs rather than making
#ifdef'ed changes to Tk_Main in the
generic area.
If that's not easy, ask me to look into
it more carefully with you.
Logged In: YES
user_id=90580
Don,
it does use Tcl_SetStartupScript(), in the new function
TkMacOSXDefaultStartupScript(), a call to which is all that is added to
Tk_Main, c.f. patch.
There seems to be no existing plaform specific function where such
code could be added, as Jim mentioned on tcl-mac, it might be
a good idea to add one (TkpDefaultStartupScript()); note that such a
function would need to be called before the startup script processing in
Tk_Main, as TkMacOSXDefaultStartupScript() is now.
Previously the code in TkMacOSXDefaultStartupScript() was in the wish
main() function, which meant that we needed a platform specific
tkMacOSXAppInit.c just for this, which affected every application wishing
to embed Tk, not just Tk itself... IMO it's preferrable to add a platform
#ifdef to Tk_Main (which has a bunch of platform specifc code already), if
that enables us to use the generic tkAppInit.c.
I'm open to suggestions on how to do this better, if you have any; I agree
that it would be nice to do this more cleanly.
Logged In: YES
user_id=90580
are there any further questions about this patch or can I move forward and
commit ?
Logged In: YES
user_id=80530
go ahead and commit. We can
deal with my remaining concerns
later.
Logged In: YES
user_id=90580
committed to HEAD and core-8-4-branch