Re: [MACTCL] tkConfig.sh

[Jim I. <ji...@ap...>]

Marc-Antoine,

On Thursday, October 18, 2001, at 09:22  PM, Marc-Antoine Parent wrote:

> 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 s/tcl/tk/g; through it (more or less ;-)
> I also added the X11 header locations.

Thanks, I will have a look.

>
> Finally, I had to put some headers into Headers as opposed to 
> PrivateHeaders (as suggested by Tony Lownds) and I could actually 
> compile my application.
> (Wow!)

Great!  I have to ask one of the compiler fellows what is the magic that 
gets the Private Headers to be seen.  It is possible, but maybe there is 
some  compiler flag needed or something.

>
> Well, I also had to adjust that application to use the #include 
> <Tk/tk.h> notation...
> Do you think we could push for the include notation to be specified in 
> the t_Config.sh-es ?
> Actually, the best would be to add a flag saying : This is a (Darwin) 
> framework. That flag could then impact both the compilation/linkage 
> flags and the import notation. I also see the import of this since 
> darwin can accommodate Tcl and Tk as either shared libraries or as 
> frameworks; and Tk as either a X11 or Aqua library. Both are valid 
> choices to different users, and the configuration files should not 
> infer either from the platform alone.
> Hence the importance of a 'framework' flag...

I am not sure whether is is best to work this into configure or do it as 
a post-processing step.  I was planning tenatively to do the "#include 
<Tcl.h>" -> "#include <Tcl/Tcl.h>" when  I moved the headers into the 
framework, I see no reason to load down the configure for all the other 
platforms with this detail, and it would be very easy to do this as a 
shell script build phase in PB.  However, I did add a framework macro to 
the tcl.m4 in tcl/unix, and use the defines in a few places in 
configure.in.  So there is some structure in place on the tcl build side 
to do this.  I tend to the PB solution myself, 'cause I like working in 
PB.  Again, if some ambitious person wants to get together the 
configure/make for Tk, I would at least use the configure part to 
generate the tkConfig.sh in my PB project...

On Darwin & frameworks...  Wilfredo was moving away from using 
Frameworks for all the Darwin stuff.  He thought it was a bad idea to 
add all this work to EVERY Unix project.  I don't know what Jordan's 
feeling on this is, however.  In my case, the Tcl build will be 
different for Mac OS X and Darwin, since I want to build in the Resource 
handling stuff, some understanding of aliases, and the AppleScript and 
maybe TclAE, and have all this be a standard part of the Tcl distro...  
So I don't think that Darwin & Mac OS X Tcl need to have the same 
distribution mechanism.

>
> (This idea goes for all Darwin frameworks, and should someday be 
> 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 
> 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 
> any mouse click by becoming selected (frontmost.) I could draw into it 
> with Mozart code, but the image in the Canvas did not refresh unless I 
> passed another window over the AquaTk window.
>

I don't know what you are doing in Mozart.  Do you mean by "AquaTk 
canvas" just the standard canvas widget - for instance are you just 
adding some more canvas item types?  Or are you just getting the window 
of a canvas widget and drawing on top of it?  Or have you written your 
own custom canvas to draw into?  The standard Canvas widget works fine, 
redraws, responds to the mouse, etc.  So you should probably look at 
what you are doing differently from all the canvas widget.

> The mozart code used to do a perfectly selectable window under 
> 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 
> 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 
> implementation? And where do you think I should go looking for those?
>

Describe more what you do, and I can give you some kind of answer.  I 
don't know enough now to speculate usefully.

Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb