#2069 embedding on OS X Aqua is problematic

[Greg Couch]

macosx/tkMacOSXInit.c's TkpInit function is not
friendly to applications that embed Tcl/Tk.

One bug is that it only works for the first Tcl
interpreter that an application creates -- this is not
a problem for the X11 and Windows versions of Tk. The
symptom is that one's ported application crashes
mysteriously because Apple events refer to a Tcl
interpreter that no longer exists.

The next bug appears once the application is rewritten
to use only one Tcl interpreter (in my case, reuse the
Tcl interpreter from the splash screen for the main
part of the application). Then an extremely helpful
console window appears (because the application was
started by double clicking and Tk thinks it was started
up via Wish.app) that is unwanted and unneeded. (The
console appeared before, but quickly disappeared when
the first Tcl interpreter was destroyed.) There is no
reasonable way to disable this behavoir without
modifying the Tk source code (I want to leave stdin
alone, thank you very much).

[Daniel A. Steffen]

Logged In: YES
user_id=90580

Greg,

the interp issue you raise is tricky, indeed the interp passed to TkpInit() the
first time it is ever called is used for several things in TkAqua: handling AE,
carbon event & default menus callback, and runtime control of text/graphics
antialiasing & graphics api via link vars.

for the callbacks, the easiest solution would be to introduce api to set the
interp used for event callbacks, would that be helpful in your situation?
the link vars are tricker, they should probably be replaced by getter/setter
procs in the tk::mac namespace that are available to all interps (backwards
compatibility might be tricky).

as far as showing the console on startup goes, doesn't Tcl_SetStartupScript
give you the control you want? if you call this (e.g. with a noop script) before
initializing Tk, the console will not be shown.

it might be best if you raised all of these issues on the tcl-mac mailing list for
discussion, IMO none of them have a simple obvious fix that I'd want to
decide on unilaterally.

[Donal K. Fellows]

Logged In: YES
user_id=79902

Please keep in mind that some of these issues might even
warrant discussion on tcl-core where you stand a good chance
of picking up more general help from people doing embedding
on other platforms.

[Jeffrey Hobbs]

[Jeffrey Hobbs]

Logged In: YES
user_id=72656
Originator: NO

See also 1601982 about the console issue. My recommendation would be to allow for tcl_interactive to be modified by the user, which would better enable the embedder to control this behavior. Attached is the recommended patch against 8.5 head, but it should be applied to 8.4 as well.

[Daniel A. Steffen]

Logged In: YES
user_id=90580
Originator: NO

Hi Jeff,
that patch looks good to me, except maybe for adding a check that tcl_interactive has not been explicitly set to 1 before TkpInit() was called? (in which case the console should be shown IMO)

any opinions on the other issues raised here? e.g. I would suggest a tk::mac::unsupported getter/setter command available in all interps instead of the tk::mac linkvars only in the first interp created (tk.tcl could add var trace for backwards compat), but I'm less sure how to handle interp selection for callback execution.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656
Originator: NO

Daniel - the patch I have only changes to [set tcl_interactive 1] if it isn't already set (currently it forces it to be set). That means any setting of tcl_interactive prior to TkpInit will remain, allowing either 1 or 0 (the latter needed by embedders). I'll commit that and comment follow-up on the other points.

[Daniel A. Steffen]

Logged In: YES
user_id=90580
Originator: NO

Sorry Jeff, ignore my previous comment, I had misread the patch and thought calling Tk_CreateConsoleWindow was made conditional on tcl_interactive being unset before TkpInit() was called (when in fact only the setting of tcl_interactive to 1 is made conditional). The misreading came from the comment
+ * Only show the console if we don't have a startup script
+ * and tcl_interactive hasn't been set already.
which is somewhat misleading because the console may be shown even if these things are true (e.g. if tcl_interactive was set to 1 before calling TkpInit()).