[Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd)

[Schollnick, Benjamin]

Potentially silly question here...

> discussion as well, IIRC). To allow the use of "-framework Python" we
> would have to modify each and every python extension module in te
> world to do #include "Python/Python.h" in stead of the current
> #include "Python.h". For Python we decided (so far) not to do this. I

Is there any reason that a symbolic (?) link couldn't be used to fix
(or work around) this problem.

for example:

python.h  ->	./python/python.h

Sure it's not ideal.... But a simple installer should be able to make
the symbolic link....

That should work... At least with informal testing that I just did in a
telnet window, with a Unix (solaris) machine, leads me to believe it might
work....

Since a link acts directly on the real file, I don't see why an import, 
or any other "compilier" access wouldn't work...

Now, during your discussion (which I didn't really pay too much attention
to), I may have missed an non-technical reason why a link wouldn't work...
Feel free to use a 10t hammer to remind me...

		- Benjamin

-----Original Message-----
From: Jack Jansen [mailto:jack@oratrix.nl]
Sent: Tuesday, October 16, 2001 4:49 PM
To: Tony Lownds
Cc: Jack Jansen; pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] ANNOUNCE: Tcl/Tk for Mac OS X (fwd)


[cc-ing Guido, as he asked me about whether I planned to do anything
about Tk. Guido: Tony has done the work, and things are somewhat
starting to work. Am I off the hook? :-)]

Recently, Tony Lownds <tony@metanet.com> said:
> * I had to put all of those -I directives that point into the 
> framework instead of just using the framework.

This is the same discussion we had about Python (you were in that
discussion as well, IIRC). To allow the use of "-framework Python" we
would have to modify each and every python extension module in te
world to do #include "Python/Python.h" in stead of the current
#include "Python.h". For Python we decided (so far) not to do this. I
think this is a problem for Apple to solve, possibly through a variant
of -framework.

The PrivateIncludes stuff does look like an error in the Tk setup,
though.

> But it compiled, import _tkinter worked, Demos/tkinter/guido/hello.py 
> produced a window. It took ages to display, never grabbed focus 
> correctly, and didn't quit when clicked but it did display.

Well, that sounds about like how Tk behaves under MacPython, HAHA:-)

BTW: I'm chatting to Jim at the moment to try and fix the "event loop
problem" now that both Python and Tk are in their infancy on OSX. I'm
referring here to the problem that the two event loops don't know
about each other, therefore get very confused when they see update
events (or other events) for each others windows, get in fights over
the menu bar, etc. This is the basic problem that makes it impossible
to run Tkinter programs from the IDE. I hope we can come up with an
API that is general enough that other packages may also be tempted to
adopt it.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig