Re: [MACTCL] tkConfig.sh

[Marc-Antoine P. <map...@ac...>]

Thank you, Jim, for a prompt answer.

Yes, I got confused between tclConfig.sh and tkConfig.sh
I took a simplistic stab at the latter by taking the former and applying=20=

s/tcl/tk/g; through it (more or less ;-)
I also added the X11 header locations.
<Fichier joint : tkConfig.sh>
Finally, I had to put some headers into Headers as opposed to=20
PrivateHeaders (as suggested by Tony Lownds) and I could actually=20
compile my application.
(Wow!)

Well, I also had to adjust that application to use the #include=20
<Tk/tk.h> notation...
Do you think we could push for the include notation to be specified in=20=

the t_Config.sh-es ?
Actually, the best would be to add a flag saying : This is a (Darwin)=20
framework. That flag could then impact both the compilation/linkage=20
flags and the import notation. I also see the import of this since=20
darwin can accommodate Tcl and Tk as either shared libraries or as=20
frameworks; and Tk as either a X11 or Aqua library. Both are valid=20
choices to different users, and the configuration files should not infer=20=

either from the platform alone.
Hence the importance of a 'framework' flag...

(This idea goes for all Darwin frameworks, and should someday be=20
implemented at the level of autoconf! OK, I'm dreaming aloud.)

On another note:
Now that I have the resulting Tk wrapper for Mozart, I attempted to use=20=

some Mozart sample code that draws on a AquaTk canvas in a window.
The window was created as an unselected window, and did not respond to=20=

any mouse click by becoming selected (frontmost.) I could draw into it=20=

with Mozart code, but the image in the Canvas did not refresh unless I=20=

passed another window over the AquaTk window.

The mozart code used to do a perfectly selectable window under=20
Tk/XFree86. (But that was under Tk 8.3, not 8.4)

Do you think that our Mozart Tk wrapper is lacking some event trapping=20=

code that appeared in Tk 8.4? (Does not feel likely!)
Or is it rather due to problems with the current state of the Tk=20
implementation? And where do you think I should go looking for those?

Thank you again,
and enjoy!

Marc-Antoine

Le Jeudi 18 octobre 2001, =E0 01:53 , Jim Ingham a =E9crit :

> Marc-Antoine,
>
> There is a little more work than just providing the tkConfig.sh.  The=20=

> tclConfig.sh file actually is in the framework (in Headers) but it=20
> doesn't work for the Framework structure yet, as opposed to the=20
> standard Unix distro.
>
> I need to figure out what has to be changed both in the *Config.sh=20
> files, and maybe in the Header files (they may have to use framework=20=

> include notation internally) to get this to all work.  I am looking=20
> into this now (I also have to take all my current changes and make=20
> TIP's for them, and try to get them accepted for the 8.4 release,=20
> however, and I have a day job, so any help here would be gladly=20
> accepted)...
>
> So if you want to take a stab at this yourself, that would be fine.  I=20=

> suggest first just hand editing the tclConfig.sh & tkConfig.sh  and=20
> manually inserting them in the headers directory of the framework,=20
> untill they work for you.  There is a tclConfig.sh already which =
almost=20
> works, but I don't use the Unix configure for Tk so there is no=20
> tkConfig.sh.  You will have to edit tkConfig.sh.in from tk/generic in=20=

> the source tree.  Then when you get something that works, look at what=20=

> we need to do to auto-generate that in the build.
>
> Once we know this, then the next step is to do this in a way that will=20=

> be easy for other extension developers to adopt.
>
> This is what I am planning to do, but I for sure won't get to it =
before=20
> the weekend.  So, if someone figures it out before me, I will be very=20=

> happy...
>
> As to what will happen with Tcl/Tk in the MacOS X distribution, I=20
> really can't say anything about that at present, sorry...
>
> Jim