tcl-mac — Q&A for Tcl on the Macintosh platform

[MACTCL] Re: TkPutImage crash on very wide images

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

Daniel,

On Sunday, December 9, 2001, at 11:31  PM, Daniel A. Steffen wrote:

> Dear All,
>
> tkMacDraw.c's TkPutImage crashes in CopyBits when using very wide 
> images.
>
> I have a case here where a Tk app (which is working fine on unix & win) 
> uses an image 4846 pixels wide (and 32 bits deep), which results in a 
> bytes_per_line value of 0x4BB8. However, according to IM, PixMap's 
> maximal value for rowBytes is 0x3FFF (c.f. [1]) and indeed CopyBits 
> crashes on the PixMap constructed by TkPutImage with
> 	pixmap.rowBytes = image->bytes_per_line | 0x8000;
> (rowBytes is a short whose high 2 bits are used as QD flags, thus the 
> 0x3FFF limit)
>
> In practical terms this means that Tk will crash when using any 32bit 
> image wider than 4095 pixels.
>
> Not sure what the best solution is here, I've now added a panic before 
> the CopyBits to at least exit gracefully, a better solution would be to 
> split the image into blocks that are maximally 0x4000 bytes wide and do 
> CopyBits on each block... The question is how common is the use of 
> images this wide, is it worth putting in time to get this to work?
>

This depends on how much free time you have.  Not many screens can 
display an image this big, so I wouldn't imagine this is all that common.

> BTW, this problem almost certainly also exist on TkAqua, as TkPutImage 
> is essentially unchanged in tkMacOSXDraw.c (and Carbon CopyBits still 
> uses Bit 15 as a flag)
>

Yes, but I would solve this problem on X not by breaking the image up, 
as you would have to on 9, but by replacing CopyBits with a CoreGraphics 
problem at some point, since that would also open the possibility of 
compositing with alpha channels as well.  So I don't think this is a 
motivation to do this work on 9 (of course, who knows when I will get 
around to this...)

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

Re: [MACTCL] Standalone on Mac OS 9x...

[Daniel A. S. <st...@ic...>]

Andrew,

sorry for the delay

At 1:44 +0000 on 6/12/01, Andrew Wilson wrote:
>How do I build a single-file download containing a standalone
>version of my pure-tcl application?
>
>I'd assumed that the answer was:
>
>1.	install the latest tcl/tk for macos 9
>2.	drop the .tcl script onto the D&D Tclet app
>3.      put the resulting app into a folder, compress it and put
>	it on the web.
>
>But it looks like I need to ensure that users of the application
>have also installed the latest tcl/tk on their own machines.  This
>is not so good...  I need the application to work on a user's
>machine even if they've got no copy of tcl/tk.
>
>If I attempt to run the application on a machine that has no tcl/tk
>installed, then starting the application results in an error dialog.
>I seems to be looking for a system/extensions/tcltkstuff (sic)
>folder, can't find it and panics.
>
>Is there a way to construct the application so that it contains
>all the necessary *.tcl library files, say in a series of resources,
>or by adding the *.tcl files to the shipped application's folder.
>It would be nice if I didn't have to install those shipped libraries
>under the system/extensions folder on the target machine.

several solutions are possible, but nothing quite as easy as freewrap 
et al on other platforms, in particular I don't know of anything 
except JCW's tclkit allowing real single file executables on MacOS.

the simplest solution is as follows:

firstly you should use the statically linked Wish ("Simple Tk (PPC)") 
as the Wish Stub for D&D Tclets.
Note that for this to work you'll either need an appropriately 
populated "(Support Libraries)" subdirectory or you can merge the ppc 
MSL & MoreFiles shared libraries from that directory directly into 
Wish using e.g. MPW's MergeFragment or other such tools.
this will obviate the need for shared Tcl & Tk libraries in the system folder.

to enable Tcl/Tk to find its encodings and packages in your local 
directory, you need to add environment variables to Wish's STR# 128 
resource ("Tcl Environment Variables"), you'll probably need both 
TCL_LIBRRARY and TK_LIBRARY, set them to e.g. ":tcl" and ":tk" and 
add corresponding subdirectories containing the minimal subset of 
"Tool Command Language:tcl8.3" and "Tool Command Language:tk8.3" 
needed to startup (you probably don't need all encoding files etc).

to allow tcl to find additional private packages you may also need to 
add other local directories to the auto_path as usual.

If you expect your users to use MacOS 9.0 or higher, you could then 
package your directory structure as a OSX-style package, this will 
give it the appearance of a single file executable in the Finder. 
(c.f. http://developer.apple.com/technotes/tn/tn1188.html)

Hope this helps

Cheers,

Daniel

-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

[MACTCL] TkPutImage crash on very wide images

[Daniel A. S. <st...@ic...>]

Dear All,

tkMacDraw.c's TkPutImage crashes in CopyBits when using very wide images.

I have a case here where a Tk app (which is working fine on unix & 
win) uses an image 4846 pixels wide (and 32 bits deep), which results 
in a bytes_per_line value of 0x4BB8. However, according to IM, 
PixMap's maximal value for rowBytes is 0x3FFF (c.f. [1]) and indeed 
CopyBits crashes on the PixMap constructed by TkPutImage with
	pixmap.rowBytes = image->bytes_per_line | 0x8000;
(rowBytes is a short whose high 2 bits are used as QD flags, thus the 
0x3FFF limit)

In practical terms this means that Tk will crash when using any 32bit 
image wider than 4095 pixels.

Not sure what the best solution is here, I've now added a panic 
before the CopyBits to at least exit gracefully, a better solution 
would be to split the image into blocks that are maximally 0x4000 
bytes wide and do CopyBits on each block... The question is how 
common is the use of images this wide, is it worth putting in time to 
get this to work?

BTW, this problem almost certainly also exist on TkAqua, as 
TkPutImage is essentially unchanged in tkMacOSXDraw.c (and Carbon 
CopyBits still uses Bit 15 as a flag)

Cheers,

Daniel

[1] 
http://developer.apple.com/techpubs/macosx/Carbon/graphics/QuickDraw/QuickDraw_Manager/DataTypes/PixMap.html
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

[MACTCL] Maxima and Tcl/Tk

[Lizardo H. C. M. N. <li...@ur...>]

Hi,

That's my first post to this list. I don't know anything about Tcl/Tk.

Well, I've just built Maxima pre-5.9. Maxima is the only open source 
nice package that I know for symbolic calculation.( Refer to 
http://maxima.sourceforge.net )

It uses Tcl/Tk for plotting and GUI. So far I've only got a command-line 
tool. So, if any Tcl/Tk guy is interested in helping me to get a fully 
working Maxima, I'd really appreciate.

Just give Maxima a try would be worthy. It's pretty trivial to build; 
instructions below for those who are interested. More details in 
maximadoc.pdf available at site above.

Thanks,
Lizardo.


Compiling maxima:

1) Get sources
Sources at CVS: once connected to the Internet, using Terminal.app type:

cvs -d:pserver:ano...@cv...:/cvsroot/maxima
login

password: < return >  <---- just press enter

Then
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/maxima
co maxima-pre59

and you create a maxima-pre59 folder

2) Get Clisp.
All you need is clisp-2.27, available with Fink
http://fink.sourceforge.net

3) Compile, 3 steps:
Go to the folder "maxima-pre59/src/"
type:
make clisp-compile CLISP=clisp

make maxima-clisp.mem CLISP=clisp

make test-clisp CLISP=clisp

you will get (luckly):
..Which was correct
Congratulations: No differences!
No Errors Found
Real time: 86.89109f0 sec.
Run time: 27.15f0 sec.
Space: 24505028 Bytes
GC: 17, GC time: 2.72f0 sec.

4)Using:
again, at "maxima-pre59/src" type

%chmod +x maxima-clisp.mem
% clisp -M maxima-clisp.mem

Maxima works. Have fun.

Re: [MACTCL] Tix for MacOS X ?

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

On 12/9/01 5:01 AM, "Ruediger Goetz" <rg...@r-...> wrote:

> 
> Hello,
> 
> I'm new to this list and I never have into coding
> TCl/Tk themselves before. However, I used programming
> for years on other fields (mainly numerics).
> 
> About a year ago I started to created PIM-Application
> for Linux (minkowsky, see www.r-goetz.de/minkowskt/ , its only
> German up to now, however). I'm using Tcl/Tk and Tix for this task.
> I choosed this Tookkits for two reasons, beeing familiar with it
> and portability.
> 
> Since the first release of minkowsky I watched out for Tk beeing available
> for MacOS X. Unfortunately I m stuck in getting Tk mand Tix running under
> MacOS X.
> 
> In order to build tix I obtained the tk-source from CVS and tried to
> build tk from  the scratch. Unfortunatelt I didn't found any install
> documention for MacOS X (or did I miss it ?). Simply doing a
> configure in the unix-subdirectory didn't work (as expected).
> But I found nothing in the macosx subdirectory but an Wish.pbproj
> folder containing nothing but CVS controll files.

Did you check out the right branch?  You should have checked out
macosx-8-4-branch to get all the files.  If there isn't a file called
project.pbxproj in the Wish.pbproj folder then something went wrong.

Anyway, look back in the archives of this list, the Announcement I sent of
the first Mac OS X Tk release has some notes on how to build the thing.

> 
> Now my questions are
> - How to build tk on  MacOS X

The Announcements notes will show you how.  Basically, you just run the main
target in the PB Project.  But it sounds like something went wrong with your
checkout.

> - Is there already a running tix for MacOS X (natively not with XDarwin)

No.

> - What problems should I expect on porting tix?
> 

I don't know, I haven't looked at it.  If it uses more of the X libraries
than is in the Wish porting layer, then you may need to fill in Mac OS X
versions of these calls.  It has been ported to Windows, however, so this
might not be a big deal.  I bet mostly it will be figuring out how to get it
built.

> If I missed some documention, pointer thereto would be appreciated as well.
> 

Besides the announcement note I sent, no.

Tell us how you get along (once you can get things to build at all :-( ),
and we will try to help out.  It would be great to get Tix going.

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Bundling Tk on Mac OS X

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

On 12/9/01 4:04 AM, "Rupert Barrow" <rb...@ma...> wrote:

> le 5/12/01 23:41, Jim Ingham =E0 ji...@ap... a =E9crit=A0:
>=20
>>>=20
> <SNIP - symlinking lib and include>
>>>=20
>>=20
>> I really don't want to have to do this.  I don't think it is a good idea=
 to
>> have two paths particularly for linking to Tcl/Tk.  If we are going to g=
ive
>> up & build other things using the Unix layout, then we should just bag u=
sing
>> frameworks altogether.  Otherwise, it will just be a source of installat=
ion
>> nightmares...  It also means that our install will collide with an X11 b=
uilt
>> version of Tk.  By using Frameworks for the Mac OS X install, we keep th=
e
>> two versions clearly separated.
>>=20
>> However, it should be possible to fix up the tclConfig.sh and generate a
>> tkConfig.sh such that other builds that use these (which is most Tcl/Tk
>> extensions these days) can find what they need just using the defines in
>> there.  I have a tclConfig.sh that works for Itcl, and my tkConfig.sh al=
most
>> works for Itk - I need another weekend to finish this off.  Then I will =
try
>> some other extensions to make sure I haven't missed anything.  But the
>> tcl.m4 & friends provide enough of an abstraction that I am pretty confi=
dent
>> I can make this work.
>=20
> OK. As a Tck/Tk user, I had never paid much attention to the *Config.sh
> files; now I understand their value. Forget about all the symlinking !

The symlinking isn't a bad idea, but the *Config.sh is a better one...

>=20
>> If you have extensions that use hand-crafted Makefiles, you really shoul=
d
>> consider moving over to the TEA Makefile style for more general reasons.
>> But even if you don't want to do this, you still don't have to change th=
at
>> much to get this working.
>=20
> I am porting an autoconfig/automake-based opensource software. What is th=
e
> TEA Makefile style ?

There is a document on the Tcl Resources page (now hosted at activestate)
describing the "Tcl Extension Architecture" and there was also a paper at
year before last's Tcl conference on this.  Basically, it means writing you=
r
makefile to use the defines that the tcl.m4 + *Config.sh set up.  Also, if
you are writing an extension that others might want to link to (like Itcl)
it tells you how to write your own *Config.sh for use with this.  There is =
a
current TIP to clarify this process as well.

>=20
>>>=20
> <SNIP - PrivateHeaders>
>>>=20
>>=20
>>=20
>> I do agree that the PrivateHeaders thingie is silly, and I will move all
>> those headers just into Headers.  There is a way to say that one framewo=
rk
>> is a "friend" of another and then gcc will include its PrivateHeaders as
>> well as its Headers on the implicit header search path it derives from t=
he
>> -framework argument.  That is how it was intended to work, though I woul=
dn't
>> be surprised if this were not all that clearly documented.  But even so,=
 it
>> seems an unnecessary complication...
>=20
> Good. BTW, should the *Config.sh go into the Headers directory ? It would=
 be
> best to put it directly under the ...Versions/8.4 root. No symlink back t=
o
> the Tk.framework wrapper root dir, since it is vital to explicitely speci=
fy
> (my opinion) a Tk version when building something which uses it.

Headers is a symlink to the Headers directory for the current version.  So
you can always pass in Versions/8.4/Headers for --with-tcl if you want to
specify the version.

>=20
> <SNIP>
>=20
>>>=20
>>> - I like the Tcl and Tk ProjectBuilder projects, although they are
>>> different. There is a problem in Tcl's : you cannot 'make clean' with t=
he
>>> broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple'=
s
>>> "copy files build phase" : well done, I will reuse that.
>>=20
>> Thanks.  The PB folks know about the copy files build phase bugs, this a=
rea
>> is undergoing some architectural renovation, and a lot of it should be
>> cleaner when this is done.  The make clean problem was just me not wanti=
ng
>> to hack into the Tcl Makefile.in more than absolutely necessary.  I don'=
t
>> think it will be to hard to fix this, however.
>=20
> It would be nice to design a possibly reusable PB template project along =
the
> lines of what you did for Tcl, to act as a wrapper for configure-based
> opensource stuff ported to MacOSX, including (of course) bundling into
> frameworks and apps. Apple, anyone listening ?

That would be me...  I did one for Classic MacOS, which Bruce Elliott & the=
n
Daniel refined.  I need to bug the PB folks to figure out how to write a
template (it is not that hard) then I can maybe do a quick version of this
which someone else can make better?

Jim
--=20
++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D++=3D
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] Tix for MacOS X ?

[Ruediger G. <rg...@r-...>]

Hello,

I'm new to this list and I never have into coding
TCl/Tk themselves before. However, I used programming
for years on other fields (mainly numerics).

About a year ago I started to created PIM-Application
for Linux (minkowsky, see www.r-goetz.de/minkowskt/ , its only
German up to now, however). I'm using Tcl/Tk and Tix for this task.
I choosed this Tookkits for two reasons, beeing familiar with it
and portability.

Since the first release of minkowsky I watched out for Tk beeing available 
for MacOS X. Unfortunately I m stuck in getting Tk mand Tix running under MacOS X.

In order to build tix I obtained the tk-source from CVS and tried to 
build tk from  the scratch. Unfortunatelt I didn't found any install 
documention for MacOS X (or did I miss it ?). Simply doing a 
configure in the unix-subdirectory didn't work (as expected).
But I found nothing in the macosx subdirectory but an Wish.pbproj
folder containing nothing but CVS controll files.

Now my questions are 
- How to build tk on  MacOS X
- Is there already a running tix for MacOS X (natively not with XDarwin)
- What problems should I expect on porting tix?

If I missed some documention, pointer thereto would be appreciated as well.

TIA

Yours 

R"udiger Goetz




-- 
R"udiger Goetz
rg...@r-...
WWW: http://www.r-goetz.de
Mail send by a Mac running Linux (SuSE-PPC)

Re: [MACTCL] Bundling Tk on Mac OS X

[Rupert B. <rb...@ma...>]

le 5/12/01 23:41, Jim Ingham =E0 ji...@ap... a =E9crit=A0:

>>=20
<SNIP - symlinking lib and include>
>>=20
>=20
> I really don't want to have to do this.  I don't think it is a good idea =
to
> have two paths particularly for linking to Tcl/Tk.  If we are going to gi=
ve
> up & build other things using the Unix layout, then we should just bag us=
ing
> frameworks altogether.  Otherwise, it will just be a source of installati=
on
> nightmares...  It also means that our install will collide with an X11 bu=
ilt
> version of Tk.  By using Frameworks for the Mac OS X install, we keep the
> two versions clearly separated.
>=20
> However, it should be possible to fix up the tclConfig.sh and generate a
> tkConfig.sh such that other builds that use these (which is most Tcl/Tk
> extensions these days) can find what they need just using the defines in
> there.  I have a tclConfig.sh that works for Itcl, and my tkConfig.sh alm=
ost
> works for Itk - I need another weekend to finish this off.  Then I will t=
ry
> some other extensions to make sure I haven't missed anything.  But the
> tcl.m4 & friends provide enough of an abstraction that I am pretty confid=
ent
> I can make this work.

OK. As a Tck/Tk user, I had never paid much attention to the *Config.sh
files; now I understand their value. Forget about all the symlinking !

> If you have extensions that use hand-crafted Makefiles, you really should
> consider moving over to the TEA Makefile style for more general reasons.
> But even if you don't want to do this, you still don't have to change tha=
t
> much to get this working.

I am porting an autoconfig/automake-based opensource software. What is the
TEA Makefile style ?

>>=20
<SNIP - PrivateHeaders>
>>=20
>=20
>=20
> I do agree that the PrivateHeaders thingie is silly, and I will move all
> those headers just into Headers.  There is a way to say that one framewor=
k
> is a "friend" of another and then gcc will include its PrivateHeaders as
> well as its Headers on the implicit header search path it derives from th=
e
> -framework argument.  That is how it was intended to work, though I would=
n't
> be surprised if this were not all that clearly documented.  But even so, =
it
> seems an unnecessary complication...

Good. BTW, should the *Config.sh go into the Headers directory ? It would b=
e
best to put it directly under the ...Versions/8.4 root. No symlink back to
the Tk.framework wrapper root dir, since it is vital to explicitely specify
(my opinion) a Tk version when building something which uses it.

<SNIP>

>>=20
>> - I like the Tcl and Tk ProjectBuilder projects, although they are
>> different. There is a problem in Tcl's : you cannot 'make clean' with th=
e
>> broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple's
>> "copy files build phase" : well done, I will reuse that.
>=20
> Thanks.  The PB folks know about the copy files build phase bugs, this ar=
ea
> is undergoing some architectural renovation, and a lot of it should be
> cleaner when this is done.  The make clean problem was just me not wantin=
g
> to hack into the Tcl Makefile.in more than absolutely necessary.  I don't
> think it will be to hard to fix this, however.

It would be nice to design a possibly reusable PB template project along th=
e
lines of what you did for Tcl, to act as a wrapper for configure-based
opensource stuff ported to MacOSX, including (of course) bundling into
frameworks and apps. Apple, anyone listening ?

Rupert

Re: [MACTCL] Some progress getting Tk to work with Ruby

[Daniel A. S. <st...@ic...>]

Jim, et al

At 17:27 -0800 on 6/12/01, Jim Ingham wrote:

>I know this.  But you do have to figure out how to make an acceptable MacOS
>X GUI app (acceptable to the Window Manager, that is).  I was suggesting
>this as the fastest way to figure out how to build one.  It doesn't look
>like any magic is getting done during the build phase, so it must be that
>Carbon gets info that makes it happy from the App package during
>initialization.  You will either need to bundle ruby as a .app, or figure
>out what you have to set to get Carbon happy, and add that to your require
>"tk" stage.=A0
>
>I don't know enough about this to tell you how to do this.  Your best bet i=
s
>to write Apple's Carbon developer's mailing list with this question.
>Someone there is bound to know the answer.
>

I have tried to find the minimal subset of conditions to make Carbon 
happy before and haven't found anything short of a more or less full 
app package that worked. in particular, from a single file MachO 
executable I don't seem to be able to satisfy Carbon's requirements 
to allow GUI to be brought up.

this would be very desirable e.g. in the tcl/tk space for things like 
doing [package require Tk] from tclsh to bring up GUI only when 
needed (e.g. in exceptional/rare circumstances) without having to 
load wish from the outset.

if anybody finds out if there is a programmatic way to convince 
Carbon to bring up the event loop in particular from a single file 
cli app, I'd be very interested...

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

Re: [MACTCL] Some progress getting Tk to work with Ruby

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

On 12/6/01 3:10 PM, "Robert Kedoin" <ro...@ke...> wrote:

> Jim:
> 
> Sorry 'bout that. A bit frazzled today. Didn't mean to call you Jeff.
> 

No prob...

>>> SUGGESTED CHANGE TO tkMacOSXInit.c:TkpInit()
>>> When a Ruby script that uses Tk starts up, it calls the following
>>> Tcl/Tk
>>> functions to get started:
>>> Tcl_FindExecutable
>>> Tcl_CreateInterp
>>> Tcl_Init
>>> Tk_Init
>>> What I noticed is that there are some very important looking functions
>>> that only get called from tkMacOSXAppInit.c:main() or
>>> tkMacOSXAppInit.c:Tcl_AppInit(). Specifically, they are
>>> tk_MacOSXSetupTkNotifier(), TkMacOSXInitAppleEvents(interp), and
>>> TkMacOSXInitMenus(interp).
>>> 
>>> I would suggest that these three functions need to be called from
>>> TkpInit() which is the platform specific code called from Tk_Init.
>> 
>> No, this won't work.  Tk_Init gets called for each interpreter that
>> loads Tk
>> (note for instance that tkConsole.c calls this as well as the
>> Tcl_AppInit).
>> But the menu init & apple events init, and the setup notifier, are only
>> done
>> once per app.  I guess we could change these functions to be
>> idempotent, but
>> since they really are for application initialization and not Tk
>> initialization specific things, this seems wrong to me.
> 
> It was just my observation that Tk_Init seems to be the critical path
> function that other libraries use to make sure that Tk is ready to be
> used. If calling these *MacOSX* functions is necessary for a Tk program
> to run correctly than I think they definitely should be part of TkpInit
> and the functions should be modified so calling them multiple times is
> not a problem.
> 
> Further, I would point out that on the Unix side, tkAppInit.c's
> implementation of Tcl_AppInit does not contain any X11 calls. It seems
> to rely on calls to the Tcl and Tk functions to initialize the
> environment for the Tk client, so it seems like something's wrong if we
> have Carbon calls in our Tcl_AppInit. (Though I confess with a quick
> look, I can't figure out where the X11 stuff all gets initialized.)
> 

Mac OS has more "application services" or rather has any, than X11.  So it
is not surprising that you don't see this on the X11 side.  Still, I don't
mind putting these calls into the Tk_Init.  You are right that this is a
little cleaner.  Would you mind doing this and sending me a patch ;-)

> 
>> How are you building this?  The easiest way to get all this right is to
>> use
>> PB, and its Carbon Application template.  Short of that, set PB to issue
>> detailed build logs (in the Build preference pane) and then build Wish,
>> and
>> see what it does, and just copy that in your Makefile.
>> 
> Jim - remember that I'm not running Wish.app *at all*. I'm using the Tk
> and Tcl dylib's to compile an extension to Ruby. Then, I'm running "gdb
> ruby" and running it appropriate arguments to run my script.

I know this.  But you do have to figure out how to make an acceptable MacOS
X GUI app (acceptable to the Window Manager, that is).  I was suggesting
this as the fastest way to figure out how to build one.  It doesn't look
like any magic is getting done during the build phase, so it must be that
Carbon gets info that makes it happy from the App package during
initialization.  You will either need to bundle ruby as a .app, or figure
out what you have to set to get Carbon happy, and add that to your require
"tk" stage.  

I don't know enough about this to tell you how to do this.  Your best bet is
to write Apple's Carbon developer's mailing list with this question.
Someone there is bound to know the answer.

> 
> By the way, here's all the small Ruby script is doing. It just puts up
> "hello" and "quit" buttons and sits in the main loop:
> 
> <code_snippet tkHelloWorld.rb>
> #!/usr/bin/env ruby
> 
> require "tk"
> 
> TkButton.new(nil,
>             'text' => 'hello',
>             'command' => proc{print "hello\n"}).pack('fill'=>'x')
> TkButton.new(nil,
>             'text' => 'quit',
>             'command' => 'exit').pack('fill'=>'x')
> 
> Tk.mainloop
> </code_snippet>
> 
> To run the program, I can type "tkHelloWorld.rb" at a Terminal window or
> "ruby tkHelloWorld.rb" or pass the path to the script as an argument to
> the run command when I'm running gdb.
> 
> This is a script which works on other platforms, so the goal is to get
> it to work on OS X with Tcl/Tk without requiring any modifications to
> the existing Ruby source (ideally).

Seems like if you want to do this, you have to do whatever the app packaging
does by hand in the require tk implementation.

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

Re: [MACTCL] Some progress getting Tk to work with Ruby

[Robert K. <ro...@ke...>]

Jim:

Sorry 'bout that. A bit frazzled today. Didn't mean to call you Jeff.

>> SUGGESTED CHANGE TO tkMacOSXInit.c:TkpInit()
>> When a Ruby script that uses Tk starts up, it calls the following 
>> Tcl/Tk
>> functions to get started:
>> Tcl_FindExecutable
>> Tcl_CreateInterp
>> Tcl_Init
>> Tk_Init
>> What I noticed is that there are some very important looking functions
>> that only get called from tkMacOSXAppInit.c:main() or
>> tkMacOSXAppInit.c:Tcl_AppInit(). Specifically, they are
>> tk_MacOSXSetupTkNotifier(), TkMacOSXInitAppleEvents(interp), and
>> TkMacOSXInitMenus(interp).
>>
>> I would suggest that these three functions need to be called from
>> TkpInit() which is the platform specific code called from Tk_Init.
>
> No, this won't work.  Tk_Init gets called for each interpreter that 
> loads Tk
> (note for instance that tkConsole.c calls this as well as the 
> Tcl_AppInit).
> But the menu init & apple events init, and the setup notifier, are only 
> done
> once per app.  I guess we could change these functions to be 
> idempotent, but
> since they really are for application initialization and not Tk
> initialization specific things, this seems wrong to me.

It was just my observation that Tk_Init seems to be the critical path 
function that other libraries use to make sure that Tk is ready to be 
used. If calling these *MacOSX* functions is necessary for a Tk program 
to run correctly than I think they definitely should be part of TkpInit 
and the functions should be modified so calling them multiple times is 
not a problem.

Further, I would point out that on the Unix side, tkAppInit.c's 
implementation of Tcl_AppInit does not contain any X11 calls. It seems 
to rely on calls to the Tcl and Tk functions to initialize the 
environment for the Tk client, so it seems like something's wrong if we 
have Carbon calls in our Tcl_AppInit. (Though I confess with a quick 
look, I can't figure out where the X11 stuff all gets initialized.)


> How are you building this?  The easiest way to get all this right is to 
> use
> PB, and its Carbon Application template.  Short of that, set PB to issue
> detailed build logs (in the Build preference pane) and then build Wish, 
> and
> see what it does, and just copy that in your Makefile.
>
Jim - remember that I'm not running Wish.app *at all*. I'm using the Tk 
and Tcl dylib's to compile an extension to Ruby. Then, I'm running "gdb 
ruby" and running it appropriate arguments to run my script.

By the way, here's all the small Ruby script is doing. It just puts up 
"hello" and "quit" buttons and sits in the main loop:

<code_snippet tkHelloWorld.rb>
#!/usr/bin/env ruby

require "tk"

TkButton.new(nil,
              'text' => 'hello',
              'command' => proc{print "hello\n"}).pack('fill'=>'x')
TkButton.new(nil,
              'text' => 'quit',
              'command' => 'exit').pack('fill'=>'x')

Tk.mainloop
</code_snippet>

To run the program, I can type "tkHelloWorld.rb" at a Terminal window or 
"ruby tkHelloWorld.rb" or pass the path to the script as an argument to 
the run command when I'm running gdb.

This is a script which works on other platforms, so the goal is to get 
it to work on OS X with Tcl/Tk without requiring any modifications to 
the existing Ruby source (ideally).
	-Rob

Re: [MACTCL] Some progress getting Tk to work with Ruby

[Tony L. <to...@me...>]

>
>SUGGESTED CHANGE TO tkMacOSXInit.c:TkpInit()
>When a Ruby script that uses Tk starts up, it calls the following 
>Tcl/Tk functions to get started:
>	Tcl_FindExecutable
>	Tcl_CreateInterp
>	Tcl_Init
>	Tk_Init
>What I noticed is that there are some very important looking 
>functions that only get called from tkMacOSXAppInit.c:main() or 
>tkMacOSXAppInit.c:Tcl_AppInit(). Specifically, they are 
>tk_MacOSXSetupTkNotifier(), TkMacOSXInitAppleEvents(interp), and 
>TkMacOSXInitMenus(interp).

I just got Python/TkAqua (Tkinter) to work. What I did was to put 
those TkMacOSX* calls in the Tkinter code directly. What stumped me 
was that TkMacOSXSetupTkNotifier must be called early, which is 
clearly documented; so I made sure it happened before 
Tcl_CreateInterp. Actually, it must be called before 
Tcl_FindExecutable as well.

>SO WHERE DOES THAT LEAVE ME ?
>Well, acutally, not much better off :-( I can now guarantee that my 
>event loop is running which is a Good Thing (TM). However, I still 
>only see the window appear when I run under gdb. And when I click on 
>the window I get a new message about SetFrontProcess failing with an 
>error code of "-600".

I think this means your executable is not a .app bundle when, to be a 
gui program, it must be.

-Tony

-- 

Re: [MACTCL] Some progress getting Tk to work with Ruby

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

> All:
> 
> I have been doing some tinkering trying to get Jeff's new Tcl and Tk for
> Mac OS X to work with Ruby. I thought I'd share some thoughts about what
> I've think I've found so far in case it's of some help to those trying
> to get Tk to work with other scripting languages.

Jeff?

> 
> As background, I initially wrote directly to Jim a few days back saying
> I tried to run a Ruby script that used Tk and nothing showed up. He
> suggested I verify that DoActualWait was getting called to listen for
> events. You should also knno that while I've been learning Ruby, I'm no
> expert. Also, this is my first time looking at Tcl/Tk internals. Please
> take the suggestions below as such and feel free to correct any
> misunderstandings I might have.
> 
> When I first began to try to debug the problem, I noticed something odd.
> When I ran Ruby under gdb a Tk-window appeared with the two buttons that
> it's supposed to have. However, I couldn't do anything with it (like
> make it key, or close it). But, when run from the command-line without
> gdb the window doesn't show up at all. So, from there, I began to try to
> track down why DoActualWait() wasn't getting called...
> 
> SUGGESTED CHANGE TO tkMacOSXInit.c:TkpInit()
> When a Ruby script that uses Tk starts up, it calls the following Tcl/Tk
> functions to get started:
> Tcl_FindExecutable
> Tcl_CreateInterp
> Tcl_Init
> Tk_Init
> What I noticed is that there are some very important looking functions
> that only get called from tkMacOSXAppInit.c:main() or
> tkMacOSXAppInit.c:Tcl_AppInit(). Specifically, they are
> tk_MacOSXSetupTkNotifier(), TkMacOSXInitAppleEvents(interp), and
> TkMacOSXInitMenus(interp).
> 
> I would suggest that these three functions need to be called from
> TkpInit() which is the platform specific code called from Tk_Init.

No, this won't work.  Tk_Init gets called for each interpreter that loads Tk
(note for instance that tkConsole.c calls this as well as the Tcl_AppInit).
But the menu init & apple events init, and the setup notifier, are only done
once per app.  I guess we could change these functions to be idempotent, but
since they really are for application initialization and not Tk
initialization specific things, this seems wrong to me.

> 
> SUGGESTED CHANGE TO tkMacOSXNotify.c:tk_MacOSXSetupTkNotifier()
> When I first added tkMacOSXNotify to TkpInit() it didn't do anything.
> After some more code reading, I found this comment in
> tkMacOSXAppInit.c:main() that made that not so surprising:
> <code_snippet>
>    /*
>     * NB - You have to swap in the Tk Notifier BEFORE you start up the
>     * Tcl interpreter for now.  It probably should work to do this
>     * in the other order, but for now it doesn't seem to.
>     */
> </code_snippet>
> 
> I would like to suggest that we add one line to the end of
> tk_MacOSXSetupTKNotifier() that reads:
>   TclInitNotifier();
> It seems that by calling Tcl_SetNotifier, we update the pointers in
> tcl_stubs, but it doesn't seem to be sufficient because the
> ThreadSpecificData, tsdPtr, keeps a pointer to the tcl_InitNotifier that
> won't be updated unless we call TclInitNotifier. Furthermore, this
> guarantees that TkMacOSXInitNotifier() gets called. And, if you look at
> the source for tclNotify.c:TclInitNotifier() it becomes very clear why
> it was working iff we swapped in the notifier before the interpreter is
> created.

Let me play with this a bit.  If it removes the hacky ordering problem, that
would be great.

> 
> SO WHERE DOES THAT LEAVE ME ?
> Well, acutally, not much better off :-( I can now guarantee that my
> event loop is running which is a Good Thing (TM). However, I still only
> see the window appear when I run under gdb. And when I click on the
> window I get a new message about SetFrontProcess failing with an error
> code of "-600".
> 
> I'm not familiar with Carbon's idea of processes and how to control, it
> but after reading the error message for "-600", I decided to try and
> call GetProcessInformation to find out more about the running process in
> hopes of finding out why I get different behavior in GDB and outside of
> GDB.
> 
> When I run outside of GDB, the process has the following properties:
> LAUNCH DONT SWITCH
> DESK ACCESSORY
> MULTI LAUNCH
> NEED SUSPEND RESUME
> CAN BACKGROUND
> DOES ACTIVATE ON FG SWITCH
> GET FRONT CLICKS
> LOCAL AND REMOTE HL EVENTS
> STATIONERY AWARE
> 
> When I run inside of GDB, the process has these very different
> properties:
> ONLY BACKGROUND
> 32 BIT COMPATIBLE
> HIGH LEVEL EVENT AWARE
> 
> The "ONLY BACKGROUND" bit being set while running under GDB explains why
> it won't let the window be set to the front. However, I don't understand:
> a) why don't I get windows when running outside of GDB
> b) how can I control what these attributes are ? Are there Carbon
> functions to declare what I want them to be ?
> 
> Thanks in advance for any thoughts or help in figuring out what to
> tinker with next.

How are you building this?  The easiest way to get all this right is to use
PB, and its Carbon Application template.  Short of that, set PB to issue
detailed build logs (in the Build preference pane) and then build Wish, and
see what it does, and just copy that in your Makefile.

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] Some progress getting Tk to work with Ruby

[Robert K. <ro...@ke...>]

All:

I have been doing some tinkering trying to get Jeff's new Tcl and Tk for 
Mac OS X to work with Ruby. I thought I'd share some thoughts about what 
I've think I've found so far in case it's of some help to those trying 
to get Tk to work with other scripting languages.

As background, I initially wrote directly to Jim a few days back saying 
I tried to run a Ruby script that used Tk and nothing showed up. He 
suggested I verify that DoActualWait was getting called to listen for 
events. You should also knno that while I've been learning Ruby, I'm no 
expert. Also, this is my first time looking at Tcl/Tk internals. Please 
take the suggestions below as such and feel free to correct any 
misunderstandings I might have.

When I first began to try to debug the problem, I noticed something odd. 
When I ran Ruby under gdb a Tk-window appeared with the two buttons that 
it's supposed to have. However, I couldn't do anything with it (like 
make it key, or close it). But, when run from the command-line without 
gdb the window doesn't show up at all. So, from there, I began to try to 
track down why DoActualWait() wasn't getting called...

SUGGESTED CHANGE TO tkMacOSXInit.c:TkpInit()
When a Ruby script that uses Tk starts up, it calls the following Tcl/Tk 
functions to get started:
	Tcl_FindExecutable
	Tcl_CreateInterp
	Tcl_Init
	Tk_Init
What I noticed is that there are some very important looking functions 
that only get called from tkMacOSXAppInit.c:main() or 
tkMacOSXAppInit.c:Tcl_AppInit(). Specifically, they are 
tk_MacOSXSetupTkNotifier(), TkMacOSXInitAppleEvents(interp), and 
TkMacOSXInitMenus(interp).

I would suggest that these three functions need to be called from 
TkpInit() which is the platform specific code called from Tk_Init.

SUGGESTED CHANGE TO tkMacOSXNotify.c:tk_MacOSXSetupTkNotifier()
When I first added tkMacOSXNotify to TkpInit() it didn't do anything. 
After some more code reading, I found this comment in 
tkMacOSXAppInit.c:main() that made that not so surprising:
<code_snippet>
     /*
      * NB - You have to swap in the Tk Notifier BEFORE you start up the
      * Tcl interpreter for now.  It probably should work to do this
      * in the other order, but for now it doesn't seem to.
      */
</code_snippet>

I would like to suggest that we add one line to the end of 
tk_MacOSXSetupTKNotifier() that reads:
	   TclInitNotifier();
It seems that by calling Tcl_SetNotifier, we update the pointers in 
tcl_stubs, but it doesn't seem to be sufficient because the 
ThreadSpecificData, tsdPtr, keeps a pointer to the tcl_InitNotifier that 
won't be updated unless we call TclInitNotifier. Furthermore, this 
guarantees that TkMacOSXInitNotifier() gets called. And, if you look at 
the source for tclNotify.c:TclInitNotifier() it becomes very clear why 
it was working iff we swapped in the notifier before the interpreter is 
created.

SO WHERE DOES THAT LEAVE ME ?
Well, acutally, not much better off :-( I can now guarantee that my 
event loop is running which is a Good Thing (TM). However, I still only 
see the window appear when I run under gdb. And when I click on the 
window I get a new message about SetFrontProcess failing with an error 
code of "-600".

I'm not familiar with Carbon's idea of processes and how to control, it 
but after reading the error message for "-600", I decided to try and 
call GetProcessInformation to find out more about the running process in 
hopes of finding out why I get different behavior in GDB and outside of 
GDB.

When I run outside of GDB, the process has the following properties:
LAUNCH DONT SWITCH
DESK ACCESSORY
MULTI LAUNCH
NEED SUSPEND RESUME
CAN BACKGROUND
DOES ACTIVATE ON FG SWITCH
GET FRONT CLICKS
LOCAL AND REMOTE HL EVENTS
STATIONERY AWARE

When I run inside of GDB, the process has these very different 
properties:
ONLY BACKGROUND
32 BIT COMPATIBLE
HIGH LEVEL EVENT AWARE

The "ONLY BACKGROUND" bit being set while running under GDB explains why 
it won't let the window be set to the front. However, I don't understand:
	a) why don't I get windows when running outside of GDB
	b) how can I control what these attributes are ? Are there Carbon 
functions to declare what I want them to be ?

Thanks in advance for any thoughts or help in figuring out what to 
tinker with next.

Robert Kedoin

[MACTCL] Instant Success-Increased Sales leads guaranteed...

[<mar...@ug...>]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Proven Sales Formula! Successful entrepreneurs around the world use our products..
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Take your pick from our range of internet marketing services – whether you want targeted search engine traffic, thousands of unique users or even targeted text messaging - We understand your market; let us help get you the Christmas bonus you really deserve: http://www.trafficwow.net 

L@@K..L@@K..L@@K..L@@K..L@@K..L@@K..L@@K..L@@K..L@@K..L@@K..L@@K

For our first time customers, not only will you get fantastic deals such as 10,000 Targeted Unique Users for just $99, we can offer your site a free health check

Start outsmarting, rather than outspending your competition - we can show you how… http://www.trafficwow.net 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is sent in compliance of the new e-mail bill: Section 301. per section 301, paragraph (a)(2)(c) of S 1618. <http://www.senate.gov/#murkowshki/commerciale-mail?s77index.html>

Further Transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply e-mail it this address with the word “REMOVE” in the subject line. mar...@tr...

[MACTCL] Standalone on Mac OS 9x...

[Andrew W. <an...@aa...>]

Hi,

it's almost the year's end so I'm trying to fill up my quota of
stupid questions before it's too late...

How do I build a single-file download containing a standalone
version of my pure-tcl application?

I'd assumed that the answer was:

1.	install the latest tcl/tk for macos 9
2.	drop the .tcl script onto the D&D Tclet app
3.      put the resulting app into a folder, compress it and put
	it on the web.

But it looks like I need to ensure that users of the application
have also installed the latest tcl/tk on their own machines.  This
is not so good...  I need the application to work on a user's
machine even if they've got no copy of tcl/tk.

If I attempt to run the application on a machine that has no tcl/tk
installed, then starting the application results in an error dialog.
I seems to be looking for a system/extensions/tcltkstuff (sic)
folder, can't find it and panics.

Is there a way to construct the application so that it contains
all the necessary *.tcl library files, say in a series of resources,
or by adding the *.tcl files to the shipped application's folder.
It would be nice if I didn't have to install those shipped libraries
under the system/extensions folder on the target machine.

I'm clearly missing something simple here, can someone point out
what it is.. or at-least only throw soft fruit? ;)

Cheers,
Ay.

an...@aw...
Cell: 07889 61 61 44                 Voice/Fax: +44 (0) 1865 513 091  

Re: [MACTCL] Bundling Tk on Mac OS X

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

Rupert,


Jim



> Hi,
> 
> With Apple's help, Jim has done a great job of bundling Tk on MacOSX in the
> form of a TK.framework. I would like to add the following requirements (for
> Tcl and Tk), which seem to span across several other frameworks on MacOSX
> (e.g. OpenGL et al., i.e. GL, AGL, GLUT, ...)  :
> 
> - in Tk.framework/Versions/<M>.<m>, I would like to :
>   ln -s . lib
>   ln -s Headers include
>   ln -s Tk libtk.dylib
>   ln -s Tk libtk.<M>.<m>.dylib
> (BTW, I always use the precise version number in my -F link option, never
> the 'Current' default : e.g. -F ...Tk.framework/Versions/8.4, not -F
> ...Tk.framework)
> 
> - in Tk.framework, we might like to add the same thing, for those who link
> against the 'Current' version :
>   ln -s . lib
>   ln -s Headers include
>   ln -s Tk libtk.dylib
>   ln -s Tk libtk.<M>.<m>.dylib
> 

I really don't want to have to do this.  I don't think it is a good idea to
have two paths particularly for linking to Tcl/Tk.  If we are going to give
up & build other things using the Unix layout, then we should just bag using
frameworks altogether.  Otherwise, it will just be a source of installation
nightmares...  It also means that our install will collide with an X11 built
version of Tk.  By using Frameworks for the Mac OS X install, we keep the
two versions clearly separated.

However, it should be possible to fix up the tclConfig.sh and generate a
tkConfig.sh such that other builds that use these (which is most Tcl/Tk
extensions these days) can find what they need just using the defines in
there.  I have a tclConfig.sh that works for Itcl, and my tkConfig.sh almost
works for Itk - I need another weekend to finish this off.  Then I will try
some other extensions to make sure I haven't missed anything.  But the
tcl.m4 & friends provide enough of an abstraction that I am pretty confident
I can make this work.

If you have extensions that use hand-crafted Makefiles, you really should
consider moving over to the TEA Makefile style for more general reasons.
But even if you don't want to do this, you still don't have to change that
much to get this working.


> - in Tk.framework/Versions/<M>.<m>/Headers, to make the framework usable, I
> have had to symlink in all the contents of PrivateHeaders :
>   for i in ../PrivateHeaders; do ln -s $i; done
> I think this 'PrivateHeaders' business is pretty useless, and the Apple
> documentation is not clear on what should go in there. So either symlink as
> I have, or put everything in Headers (I prefer the symlink solution, because
> it clearly shows which headers are the public interface).
>


I do agree that the PrivateHeaders thingie is silly, and I will move all
those headers just into Headers.  There is a way to say that one framework
is a "friend" of another and then gcc will include its PrivateHeaders as
well as its Headers on the implicit header search path it derives from the
-framework argument.  That is how it was intended to work, though I wouldn't
be surprised if this were not all that clearly documented.  But even so, it
seems an unnecessary complication...
 
> All this symlink-ing makes it easier to configure&build other stuff which
> uses Tcl or Tk without having to think too much.
> BTW [OT], it would be nice to be able to use something like the
> "--enable-framework" configure option to tell this thing's libtool to link
> to (for example) the Tk framework and not the Tk *.dylib, and generate a
>   -F...Tk.framework/Versions/8.4 Tk
> link option instead of
>   -L...Tk.framework/lib -ltk8.4

The --enable-framework should be recorded when you build Tcl/Tk, and then
the other extensions should just pull the "how to link with Tcl" define out
of the tclConfig.sh, and they would automatically do the right thing.  I
think this is much cleaner than all this cross-linking.  The
--enable-framework can also be used in other extensions to modify their
*Config.sh files to generate Framework linking to their libraries, if you
decide to wrap their Makefiles in a Framework builder as I did for Tcl.

> 
> - I like the Tcl and Tk ProjectBuilder projects, although they are
> different. There is a problem in Tcl's : you cannot 'make clean' with the
> broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple's
> "copy files build phase" : well done, I will reuse that.

Thanks.  The PB folks know about the copy files build phase bugs, this area
is undergoing some architectural renovation, and a lot of it should be
cleaner when this is done.  The make clean problem was just me not wanting
to hack into the Tcl Makefile.in more than absolutely necessary.  I don't
think it will be to hard to fix this, however.

Jim
-- 
+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] RE: couldn't post question

[Jeff H. <Je...@Ac...>]

Lisa,

tcl-mac is the right list that you want.  However, in this case, I think you
are out of luck.  Perl/Tk, AFAIK, has never advanced beyond Tk 8.0.  It's
likely that you can still get Perl/Tk for Mac OS X, but only one that works in
XWindows mode.
  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
      Tcl Support and Productivity Solutions


  -----Original Message-----
  From: Lisa Woodward [mailto:li...@pi...]
  Sent: December 3, 2001 4:26 PM
  To: je...@ac...
  Subject: couldn't post question


  Hello Jeff,

  I tried to post a question to the web site but repeatedly could not. So I've
sent the post to you instead. Can you put it up? Or maybe you have the answer?

  Thanks- Lisa


    Subject: newbie: mac os x and TK tool set

    Hi,

    I am a complete novice at this and I hope I am posting the right question
to the right group.

    I am running Mac OS X (10.1) and I would like to run a unix application
called tg1_81.pl . In the documentation for this program it states "tg.pl: if
you are using Linux or Unix (note: you must have PERL installed with the
Perl/TK tool set)" .

    So I downloaded MacOSXTk8.4a4 from the apple site. How do I use this
product to get the Perl/TK tool set?

    Please answer in the most basic terms. My knowlegde of unix is extremely
elementary.

    Thanks in advance,

    Lisa

Re: [MACTCL] RE: OS X port to tk

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

Joann,

The binaries there should work fine on 10.1.  I bet it is just not finding
its shared libraries.  Did you put Tcl.framework & Tk.framework in either
~/Library/Frameworks or /Library/Frameworks?  If not, then the wish app
can't find its frameworks.

You can confirm this, or get more info, by starting the Wish Shell app from
the Terminal, and see what errors come out.  Just do the following: in
Terminal, do:

    cd /Volumes/Whereever/You/Put/Wish
    "Wish Shell.app/Contents/MacOS/Wish Shell"

Then you should see the errors from whoever is complaining.  If it is just
the framework, then you can fix this easily.  Otherwise, put send me
whatever errors you get from the above experiment, and I will take a look.

Jim

> Joann,
> 
> I'm referring this to the tcl-mac mailing list, since I am
> unfortunately Mac OS X impaired :(.  Jim Ingham was the man
> who did the compile, so he should know if noone else.  All
> the thanks for porting Tk to OS X actually goes to Jim and
> his slave ;) that was graciously funded by Apple (Jim, sorry,
> I never saw the name for your cohort).
> 
> BTW, UofO is my alma mater (many moons ago).  Go Ducks!
> 
> Jeff Hobbs                     The Tcl Guy
> Senior Developer               http://www.ActiveState.com/
>     Tcl Support and Productivity Solutions
> 
> 
>> -----Original Message-----
>> From: nobody [mailto:no...@so...]On Behalf Of Joann Loos
>> Sent: December 4, 2001 12:52 AM
>> To: jef...@ac...
>> Subject: OS X port to tk
>> 
>> 
>> Is the OS X of tk on sorce forge (tk 8.3.4) compiled
>> under OS 10.1?  When I doubleclick on the wish app,
>> the app expands, but nothing appears in the dock.  I got
>> this same behavior with developers tools when I
>> upgraded the os from 10.0 to 10.1 and didn't upgrade
>> the tools.  
>> 
>> P.S. Thank you for porting tk.  I've been trying to do a
>> prototype in Java Swing for a class and it's been driving
>> me NUTS!!
>> 
>> Joann
>> 
> 
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 

-- 
+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==
Jim Ingham                              ji...@ap...
Developer Tools - gdb

[MACTCL] RE: OS X port to tk

[Jeff H. <Je...@Ac...>]

Joann,

I'm referring this to the tcl-mac mailing list, since I am
unfortunately Mac OS X impaired :(.  Jim Ingham was the man
who did the compile, so he should know if noone else.  All
the thanks for porting Tk to OS X actually goes to Jim and
his slave ;) that was graciously funded by Apple (Jim, sorry,
I never saw the name for your cohort).

BTW, UofO is my alma mater (many moons ago).  Go Ducks!

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
      Tcl Support and Productivity Solutions


> -----Original Message-----
> From: nobody [mailto:no...@so...]On Behalf Of Joann Loos
> Sent: December 4, 2001 12:52 AM
> To: jef...@ac...
> Subject: OS X port to tk
> 
> 
> Is the OS X of tk on sorce forge (tk 8.3.4) compiled 
> under OS 10.1?  When I doubleclick on the wish app, 
> the app expands, but nothing appears in the dock.  I got 
> this same behavior with developers tools when I 
> upgraded the os from 10.0 to 10.1 and didn't upgrade 
> the tools.  
> 
> P.S. Thank you for porting tk.  I've been trying to do a 
> prototype in Java Swing for a class and it's been driving 
> me NUTS!!
> 
> Joann
> 

[MACTCL] perl/Tk for aqua based Tcl/Tk?

[Robert M. <bo...@im...>]

Is there anyone out there working on porting Tk.pm (whatever the latest 
rev is..) to MacOSX?

With that module, the floodgates would open, allowing several tools to 
be useable on the mac.

bob..

[MACTCL] Bundling Tk on Mac OS X

[Rupert B. <rb...@ma...>]

Hi,

With Apple's help, Jim has done a great job of bundling Tk on MacOSX in the
form of a TK.framework. I would like to add the following requirements (for
Tcl and Tk), which seem to span across several other frameworks on MacOSX
(e.g. OpenGL et al., i.e. GL, AGL, GLUT, ...)  :

- in Tk.framework/Versions/<M>.<m>, I would like to :
    ln -s . lib
    ln -s Headers include
    ln -s Tk libtk.dylib
    ln -s Tk libtk.<M>.<m>.dylib
(BTW, I always use the precise version number in my -F link option, never
the 'Current' default : e.g. -F ...Tk.framework/Versions/8.4, not -F
...Tk.framework)

- in Tk.framework, we might like to add the same thing, for those who link
against the 'Current' version :
    ln -s . lib
    ln -s Headers include
    ln -s Tk libtk.dylib
    ln -s Tk libtk.<M>.<m>.dylib

- in Tk.framework/Versions/<M>.<m>/Headers, to make the framework usable, I
have had to symlink in all the contents of PrivateHeaders :
    for i in ../PrivateHeaders; do ln -s $i; done
I think this 'PrivateHeaders' business is pretty useless, and the Apple
documentation is not clear on what should go in there. So either symlink as
I have, or put everything in Headers (I prefer the symlink solution, because
it clearly shows which headers are the public interface).

All this symlink-ing makes it easier to configure&build other stuff which
uses Tcl or Tk without having to think too much.
BTW [OT], it would be nice to be able to use something like the
"--enable-framework" configure option to tell this thing's libtool to link
to (for example) the Tk framework and not the Tk *.dylib, and generate a
    -F...Tk.framework/Versions/8.4 Tk
link option instead of
    -L...Tk.framework/lib -ltk8.4

- I like the Tcl and Tk ProjectBuilder projects, although they are
different. There is a problem in Tcl's : you cannot 'make clean' with the
broom ! In Tk's, Jim worked nicely around some *glaring* bugs in Apple's
"copy files build phase" : well done, I will reuse that.

TTFN,
Rupert

Re: [MACTCL] pulsing wish window

[Daniel A. S. <st...@ic...>]

At 12:48 -0500 on 28/11/01, Robert Karen wrote:

>When I source this file in wish 8.0.5 on macOS 8.0 or 8.5,
>it builds 4 listboxes horzontally aligned and a vertical scrollbar.
>If I don't add '-padx 1' (1 or more) to the grid command of the
>scrollbar or
>one of its parent frames, my toplevel pulses at the point where
>the scrollbar touches it. Bug? Fixed in later releases?

Robert,

I see this as well, both in 8.3.4 and 8.4a4, so it's definitely a bug 
that still exists. I'll try to look into it.

Could you please report this as a bug on sourceforge: 
https://sourceforge.net/tracker/?func=add&group_id=12997&atid=112997
and assign it to me (das)? please attach your test script.

Thanks

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>

[MACTCL] pulsing wish window

[Robert K. <ro...@na...>]

When I source this file in wish 8.0.5 on macOS 8.0 or 8.5,
it builds 4 listboxes horzontally aligned and a vertical scrollbar.
If I don't add '-padx 1' (1 or more) to the grid command of the
scrollbar or
one of its parent frames, my toplevel pulses at the point where
the scrollbar touches it. Bug? Fixed in later releases?

Thanks.

Robert Karen

#--------------------------------------------
proc filenameListsTestCase {parent {okButton {}} {searchButtonCmdPrefix
""}} {
# creates 4 parallel listboxes and an entry for the result.
# returns a list containing:
# 1. the new frame that holds them all. a child of $parent 
# 2. and the runidEntry path.
# 3. search button path, if it exists.
# if searchButtonCmdPrefix is included, create a search button adjacent
to entry box,
# if searchButtonCmdPrefix is null, then the
# search button, if it exists, is in a different place in the window.

  global tcl_platform
  if {![winfo exists $parent]} {
    tk_messageBox -icon error -title "New age" \
      -message "Usage: filenameLists <parent>. Parent must exist."
  }

  set run_parent [frame $parent.l]
  # set up for runid list
  set listFrame [frame $run_parent.frame]
  set runidListName "$listFrame.list"
  set runidListName1 [listbox $listFrame.list1 -width 20 \
    -height 12]
  set runidListName2 [listbox $listFrame.list2 -width 10 \
    -height 12 ]
  set runidListName3 [listbox $listFrame.list3 -width 11 \
    -height 12 ]
  set runidListName4 [listbox $listFrame.list4 -width 11 \
    -height 12 ]
  scrollbar $listFrame.scr -orient vertical 
    #-command "scrollRunidList $runidListName"

  grid $runidListName1 $runidListName2 $runidListName3 $runidListName4
$listFrame.scr -sticky ns 
  grid $runidListName1 $runidListName2 $runidListName3 $runidListName4 \
    -sticky we
  grid $listFrame.scr -sticky ns
  grid $listFrame -sticky nsew -pady 0 ;# -padx 1
  pack $run_parent -expand true -fill both
  return $run_parent
}

toplevel .t; frame .t.f; set tmp [filenameListsTestCase .t.f]; pack .t.f
puts "you should see a fast wiggling of the right border of the 
scrollbar/edge of window. if you uncomment the -padx 1 near the bottom
of the proc in the line
'grid \$listFrame -stikcy nsew -pady y 0' it stops 
the wiggle effect"
puts "more info:
%array get tcl_platform
byteOrder bigEndian osVersion 8.0 machine ppc platform macintosh os
MacOS
%info patch
8.0.5
I get same result on machine with macOS 8.5.
"

[MACTCL] Tkspline Mac build

[Mats B. <ma...@pr...>]

Hi all,

I've made a Mac build of Tkspline 0.4.
Download from "http://hem.fyristorg.com/matben/download/Tkspline0.4.sit"

/Mats