You can subscribe to this list here.
2001 |
Jan
|
Feb
(20) |
Mar
(29) |
Apr
(10) |
May
(10) |
Jun
(7) |
Jul
(6) |
Aug
(59) |
Sep
(19) |
Oct
(55) |
Nov
(22) |
Dec
(40) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(56) |
Feb
(71) |
Mar
(179) |
Apr
(41) |
May
(26) |
Jun
(52) |
Jul
(62) |
Aug
(19) |
Sep
(87) |
Oct
(188) |
Nov
(95) |
Dec
(30) |
2003 |
Jan
(83) |
Feb
(119) |
Mar
(174) |
Apr
(77) |
May
(85) |
Jun
(52) |
Jul
(67) |
Aug
(121) |
Sep
(147) |
Oct
(96) |
Nov
(89) |
Dec
(144) |
2004 |
Jan
(92) |
Feb
(172) |
Mar
(205) |
Apr
(201) |
May
(105) |
Jun
(42) |
Jul
(94) |
Aug
(109) |
Sep
(81) |
Oct
(59) |
Nov
(84) |
Dec
(68) |
2005 |
Jan
(56) |
Feb
(57) |
Mar
(183) |
Apr
(139) |
May
(131) |
Jun
(178) |
Jul
(62) |
Aug
(42) |
Sep
(95) |
Oct
(47) |
Nov
(73) |
Dec
(47) |
2006 |
Jan
(66) |
Feb
(31) |
Mar
(51) |
Apr
(20) |
May
(49) |
Jun
(26) |
Jul
(23) |
Aug
(65) |
Sep
(67) |
Oct
(26) |
Nov
(16) |
Dec
(8) |
2007 |
Jan
(18) |
Feb
(43) |
Mar
(43) |
Apr
(16) |
May
(33) |
Jun
(48) |
Jul
(34) |
Aug
(7) |
Sep
(9) |
Oct
(55) |
Nov
(44) |
Dec
(73) |
2008 |
Jan
(37) |
Feb
(97) |
Mar
(44) |
Apr
(33) |
May
(79) |
Jun
(11) |
Jul
(66) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(12) |
Dec
(19) |
2009 |
Jan
(12) |
Feb
(13) |
Mar
(19) |
Apr
(30) |
May
(59) |
Jun
(22) |
Jul
(11) |
Aug
(59) |
Sep
(82) |
Oct
(25) |
Nov
(51) |
Dec
(27) |
2010 |
Jan
(27) |
Feb
(8) |
Mar
(29) |
Apr
(9) |
May
(39) |
Jun
(6) |
Jul
(8) |
Aug
(22) |
Sep
(33) |
Oct
(8) |
Nov
(35) |
Dec
(9) |
2011 |
Jan
(62) |
Feb
(19) |
Mar
(31) |
Apr
(19) |
May
(1) |
Jun
(1) |
Jul
(17) |
Aug
(10) |
Sep
(14) |
Oct
(11) |
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
(11) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(7) |
Jul
(22) |
Aug
(22) |
Sep
(30) |
Oct
(23) |
Nov
(19) |
Dec
|
2013 |
Jan
(6) |
Feb
(1) |
Mar
(10) |
Apr
(7) |
May
(3) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(9) |
Oct
(14) |
Nov
(9) |
Dec
(5) |
2014 |
Jan
(13) |
Feb
(1) |
Mar
(6) |
Apr
(3) |
May
(5) |
Jun
(2) |
Jul
(20) |
Aug
(6) |
Sep
(26) |
Oct
(25) |
Nov
(20) |
Dec
(41) |
2015 |
Jan
(9) |
Feb
(35) |
Mar
(9) |
Apr
(28) |
May
(20) |
Jun
(3) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
(3) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(12) |
Jun
(35) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
2017 |
Jan
(28) |
Feb
(14) |
Mar
(4) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
(8) |
2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(7) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(10) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(4) |
Apr
(21) |
May
(8) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
(10) |
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
From: Jim I. <ji...@ap...> - 2001-10-23 00:28:04
|
This is a bug... I was trying to be clever and not run the AppInit.tcl script unless I got just 1 argument, so it would run from the terminal as well. I tested it with the "open" terminal command: open "Wish Shell.app" and it worked, but it turns out if you double click from the finder your app gets launched with another argument (-psn_xxxxx) presumably your app's process ID... So this code didn't worked. I checked a fix into the cvs tree, so if you are comfortable with rebuilding Tcl & Tk you can do that. I have a few more things to fix before I put up new binaries, but I will do that later this week. Jim On Monday, October 22, 2001, at 05:00 PM, Tony Lownds wrote: > I wanted to try the AppInit.tcl script, but had no luck: > > ironchef:~% cat /Applications/Wish\ > Shell.app/Contents/Resources/Scripts/AppMain.tcl > set demo [file join $tk_library demos/widget] > tk_messageBox -message $demo > source $demo > > > Maybe I just have the reverse-Midas-touch or something. Does the above > location look right? Any reason the tcl code above would work in the > console but not in AppMain.tcl? > > Running the widget demo in Tk/Aqua is *very* impressive. For a first > release (difficulty of embedding aside :), everything runs really > smoothly! > > -Tony > -- > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Jim I. <ji...@ap...> - 2001-10-23 00:25:07
|
All the initialization we do is in tclMacOSXAppInit.c, but you don't need to do some of it. The stuff in main, other than Tk_MacOSXSetupTkNotifier, and the call to Tk_Main, are just convenience bits I put in there to allow you a make "double-clickable app" out of a Tcl script without having to recompile anything. Then in TclAppInit, you don't need the console window stuff if you don't want it. Everything else is necessary, I think. Jim On Monday, October 22, 2001, at 04:54 PM, Tony Lownds wrote: > > Jim, if someone is trying to embed Tk/Aqua using a straightforward > approach of using Tcl_AppInit() and Tk_Main(), what extra calls (beyond > what's necessary in X11 Tcl/Tk) does one need to make? Everything in > tkMacOSXAppInit? Or just Tk_MacOSXSetupTkNotifier()? > > -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Tony L. <to...@me...> - 2001-10-23 00:01:28
|
I wanted to try the AppInit.tcl script, but had no luck: ironchef:~% cat /Applications/Wish\ Shell.app/Contents/Resources/Scripts/AppMain.tcl set demo [file join $tk_library demos/widget] tk_messageBox -message $demo source $demo Maybe I just have the reverse-Midas-touch or something. Does the above location look right? Any reason the tcl code above would work in the console but not in AppMain.tcl? Running the widget demo in Tk/Aqua is *very* impressive. For a first release (difficulty of embedding aside :), everything runs really smoothly! -Tony -- |
From: Tony L. <to...@me...> - 2001-10-22 23:54:32
|
> >Ah, I see. If you run this from the console, you will notice that >you get an error when you click to bring it to the foreground, which >looks like: > >SetFrontProcess failed,-600 > >-600 is supposed to mean "unrecognized drag recipient" but really >probably just means that we aren't registered as a real app with the >Window Server. You can do this either by having the appropriate >MacOS resource bits (kind, etc) or by being in an App package. I >bet you can even poke these bits in directly, but I don't know how. Yes, I get this exact message when running the a.out compiled from tkMacOSXAppInit.c, so that explains that, thanks. I'm not getting that behavior from Python+tkinter yet. So far it won't show a window until I either hit Ctrl-C (when invoking a non-.app python) or Force-Quit the app (when invoking Python.app). Then the window shows, and python exits. So, instead of the window showing without responding, no window shows until a Ctrl-C gets to it. But at least we know that for Tkinter to ever work, it must smell like a Mac OS X application and not a unix command line application. Jack, you mentioned that Python is not multi-threaded internally - which is true of course - but when you build Python with threads you get different code in Tkinter's mainloop function. So whether Python was configured with threads might make a difference. Without threads Tkinter's mainloop boils down to: while (!exception_occurred && Tk_GetNumMainWindows() > 0 > 0) { Tcl_DoOneEvent(0); } With threads Tkinter's mainloop boils down to: while (!exception_occurred && Tk_GetNumMainWindows() > 0) { Tcl_DoOneEvent(TCL_DONT_WAIT); let other python threads run while sleeping for a short time } Jim, if someone is trying to embed Tk/Aqua using a straightforward approach of using Tcl_AppInit() and Tk_Main(), what extra calls (beyond what's necessary in X11 Tcl/Tk) does one need to make? Everything in tkMacOSXAppInit? Or just Tk_MacOSXSetupTkNotifier()? -Tony -- |
From: Jim I. <ji...@ap...> - 2001-10-22 23:00:52
|
Marc-Antoine, On Monday, October 22, 2001, at 03:14 PM, Parent, Marc-Antoine wrote: > Thanks a lot for the info, Jim. > > Now, we all know better where we stand. > > Let me make sure I got it straight: > > What you are saying is that, even if I invoke the executable directly > from the CLI while it lives within the .app package, it will inherit > the .app attributes properly. But invoking a CLI executable from > without a .app, it will not exist in the Window manager's eye... > Interesting! > I didn't expect that, but it seems to be the case... > Does this have anything to do with the code for finding the resources > that makes up most of tkMacOSXAppInit.c? Not really. > In particular, suppose I was forced to keep the executable out of a > .app, could I use this code to tell the application programmatically > about another location to look for the necessary resources? > (Or are they resource bits in the file's meta-data, not in the resource > fork or .app equivalent?) > The bit that is in main won't work, since it is referring to the main bundle, which if you ain't an app, you ain't got one of. But the Tk_MacOSXOpenBundleResources will still work. > (Going the PEF route appeals to me less, for some reason...) You can have resources in a Mach-O binary, the object file format, and the presence of a resource fork are orthogonal. But still, the app package is a better way to go: it is more flexible, since if you want to stuff random resources into the app package, you don't have to invent a resource type for them, and resources are, while still supported, not looked on as kindly as they once were... Jim > > Marc-Antoine > >> Ah, I see. If you run this from the console, you will notice >> that you >> get an error when you click to bring it to the foreground, >> which looks >> like: >> >> SetFrontProcess failed,-600 >> >> -600 is supposed to mean "unrecognized drag recipient" but really >> probably just means that we aren't registered as a real app with the >> Window Server. You can do this either by having the >> appropriate MacOS >> resource bits (kind, etc) or by being in an App package. I >> bet you can >> even poke these bits in directly, but I don't know how. >> >> So... if you were building as a classic Mac Application with >> a resource >> fork, you can continue to build that way, and it will work >> (there are a >> bunch of Carbon PEF applications, like NewsWatcher and >> GliderPro that do >> it this way). Or you can be an app package. But if you don't make >> yourself known somehow to the Window System, then it won't recognize >> your existance. The app will still draw & update itself, it >> just can't >> be foregrounded. Or at least that is what happened to Wish >> Shell if I >> just drag it out of the App package and try to run it somewhere else. >> >> Jim -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer >> > > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Parent, Marc-A. <Marc-Antoine_Parent@Mitel.COM> - 2001-10-22 22:19:59
|
Thanks a lot for the info, Jim. Now, we all know better where we stand.=20 Let me make sure I got it straight:=20 What you are saying is that, even if I invoke the executable directly = from the CLI while it lives within the .app package, it will inherit the = .app attributes properly. But invoking a CLI executable from without a = .app, it will not exist in the Window manager's eye... Interesting! Does this have anything to do with the code for finding the resources = that makes up most of tkMacOSXAppInit.c? In particular, suppose I was forced to keep the executable out of a = .app, could I use this code to tell the application programmatically = about another location to look for the necessary resources? (Or are they resource bits in the file's meta-data, not in the resource = fork or .app equivalent?) (Going the PEF route appeals to me less, for some reason...) =20 Marc-Antoine > Ah, I see. If you run this from the console, you will notice=20 > that you=20 > get an error when you click to bring it to the foreground,=20 > which looks=20 > like: >=20 > SetFrontProcess failed,-600 >=20 > -600 is supposed to mean "unrecognized drag recipient" but really=20 > probably just means that we aren't registered as a real app with the=20 > Window Server. You can do this either by having the=20 > appropriate MacOS=20 > resource bits (kind, etc) or by being in an App package. I=20 > bet you can=20 > even poke these bits in directly, but I don't know how. >=20 > So... if you were building as a classic Mac Application with=20 > a resource=20 > fork, you can continue to build that way, and it will work=20 > (there are a=20 > bunch of Carbon PEF applications, like NewsWatcher and=20 > GliderPro that do=20 > it this way). Or you can be an app package. But if you don't make=20 > yourself known somehow to the Window System, then it won't recognize=20 > your existance. The app will still draw & update itself, it=20 > just can't=20 > be foregrounded. Or at least that is what happened to Wish=20 > Shell if I=20 > just drag it out of the App package and try to run it somewhere else. >=20 > Jim > -- > Jim Ingham ji...@ap... > Developer Tools - gdb > Apple Computer >=20 |
From: Jim I. <ji...@ap...> - 2001-10-22 21:40:41
|
Jack, On Monday, October 22, 2001, at 12:25 PM, Jack Jansen wrote: > > Recently, Jim Ingham <ji...@ap...> said: >>> My guess is that the application indeed has to be a .app to be able to >>> handle >>> event input. When I tried to put up dialogs from a command-line Python >>> I saw >>> the same thing: the dialogs would show, but they would not react. >>> >> >> I don't think this is a correct guess. Most of the Carbon PEF >> applications that run on X don't come in App packages. And there are >> several command line utilities on X that use Carbon for UI, either to >> put up warning dialogs (some of the installer stuff does this) or to >> put >> up Authorization panels. >> >> My guess is you are being bitten by Carbon's not playing very nicely in >> a threaded environment (IIRC, Python uses multiple threads). > > Ah, this is *very* useful information, it'll undoubtedly save me a lot > of work in the future. > > But: I don't think this is the problem right now, at least, if I read > your message correctly (only call RNE in the thread that loaded > Carbon). First, Python isn't multithreaded internally, so if you don't > start threads there's only the main thread. Second, Tony reported that > a standalone > cc tkMacOSXAppInit.c -o a.out > exhibited the same problems. Ah, I see. If you run this from the console, you will notice that you get an error when you click to bring it to the foreground, which looks like: SetFrontProcess failed,-600 -600 is supposed to mean "unrecognized drag recipient" but really probably just means that we aren't registered as a real app with the Window Server. You can do this either by having the appropriate MacOS resource bits (kind, etc) or by being in an App package. I bet you can even poke these bits in directly, but I don't know how. So... if you were building as a classic Mac Application with a resource fork, you can continue to build that way, and it will work (there are a bunch of Carbon PEF applications, like NewsWatcher and GliderPro that do it this way). Or you can be an app package. But if you don't make yourself known somehow to the Window System, then it won't recognize your existance. The app will still draw & update itself, it just can't be foregrounded. Or at least that is what happened to Wish Shell if I just drag it out of the App package and try to run it somewhere else. Jim -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Jack J. <ja...@or...> - 2001-10-22 19:25:56
|
Recently, Jim Ingham <ji...@ap...> said: > > My guess is that the application indeed has to be a .app to be able to > > handle > > event input. When I tried to put up dialogs from a command-line Python > > I saw > > the same thing: the dialogs would show, but they would not react. > > > > I don't think this is a correct guess. Most of the Carbon PEF > applications that run on X don't come in App packages. And there are > several command line utilities on X that use Carbon for UI, either to > put up warning dialogs (some of the installer stuff does this) or to put > up Authorization panels. > > My guess is you are being bitten by Carbon's not playing very nicely in > a threaded environment (IIRC, Python uses multiple threads). Ah, this is *very* useful information, it'll undoubtedly save me a lot of work in the future. But: I don't think this is the problem right now, at least, if I read your message correctly (only call RNE in the thread that loaded Carbon). First, Python isn't multithreaded internally, so if you don't start threads there's only the main thread. Second, Tony reported that a standalone cc tkMacOSXAppInit.c -o a.out exhibited the same problems. So, if it's not the .app that is the problem there is something else that needs to be done before you can use events, and that both Python and this simple test program don't do. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jac...@or... | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm |
From: Jim I. <ji...@ap...> - 2001-10-22 17:25:22
|
Jack, On Monday, October 22, 2001, at 03:27 AM, Jack Jansen wrote: >> While messing around with Tkinter, I'm having similar problems: >> >> Without adding any MacOSX specific code to Tkinter, the window Tk >> creates never responds to anything. I tried adding what I thought was >> the relevant code from tkMacOSXAppInit.c(*), and that didn't fix it... >> >> So, I tried compiling tkMacOSXAppInit.c alone to see if my problems >> were in how I was compiling the stuff - basically just did >> >> cc tkMacOSXAppInit.c -o a.out >> >> with a lot of -I's and -framework's >> >> And I got the same behavior! The window did not respond to events! >> Which leads me to wonder if I have to make a .app and not a plain >> binary. Jim, does that sound correct? Would the application need to >> be a .app? > > My guess is that the application indeed has to be a .app to be able to > handle > event input. When I tried to put up dialogs from a command-line Python > I saw > the same thing: the dialogs would show, but they would not react. > I don't think this is a correct guess. Most of the Carbon PEF applications that run on X don't come in App packages. And there are several command line utilities on X that use Carbon for UI, either to put up warning dialogs (some of the installer stuff does this) or to put up Authorization panels. My guess is you are being bitten by Carbon's not playing very nicely in a threaded environment (IIRC, Python uses multiple threads). Unless you are willing to go through a lot of pain, if your app is multi-threaded you have to be sure to call ReceiveNextEvent, or whatever else you are using to fetch events from the WindowServer, on the thread on which Carbon is initialized - let's call this the Carbon thread. It turns out that the Carbon initialization generally happens in the dyld init routine for HIToolbox, so unless you play around alot with loading shared libraries, the Carbon thread will be the main thread of your application. The problem is that ReceiveNextEventis a little more general on Carbon than in Classic. It pulls events off the queue that is associated with the current thread - regardless of what the source of events is for that thread. However, so far as I can tell, Carbon only deposits events onto the Carbon thread in the application. So if you call RNE on a subsidiary thread, it won't even see any events unless some other thread takes them off the main thread's event queue, and transfers them to the waiting thread. This caused us no end of trouble when we were trying to port Tk originally. Maybe this is what is going on? Jim -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Jack J. <ja...@or...> - 2001-10-22 10:27:11
|
> While messing around with Tkinter, I'm having similar problems: > > Without adding any MacOSX specific code to Tkinter, the window Tk > creates never responds to anything. I tried adding what I thought was > the relevant code from tkMacOSXAppInit.c(*), and that didn't fix it... > > So, I tried compiling tkMacOSXAppInit.c alone to see if my problems > were in how I was compiling the stuff - basically just did > > cc tkMacOSXAppInit.c -o a.out > > with a lot of -I's and -framework's > > And I got the same behavior! The window did not respond to events! > Which leads me to wonder if I have to make a .app and not a plain > binary. Jim, does that sound correct? Would the application need to > be a .app? My guess is that the application indeed has to be a .app to be able to handle event input. When I tried to put up dialogs from a command-line Python I saw the same thing: the dialogs would show, but they would not react. I asked on the Carbon development mailing list whether (a) there was a way around this, so a commandline tool, could become a first class Aqua citizen or (b) there was a way whereby code could detect whether is was running in a .app or in a command line tool. Unfortunately I received no replies whatsoever. I would be happy if someone here could point me in the right direction... And, Tony, about the specific Tkinter/Python problem: look in Mac/OSX in the Python source tree. There you'll find instructions for creating a Python .app. It's clunky currently, as you really have to create an applet with the .app to be able to run something, but it works as a proof of concept, and it should get your Tk events flowing. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jac...@or... | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm |
From: Jim I. <ji...@ap...> - 2001-10-21 19:56:11
|
Mats, > > Intercept is perhaps a better word for it. My point is that it stops > other > extensions from doing the same thing. > Right, though we could fix this by having the Tcl_MacSetEventProc return the old event proc, so you could route through it. But I don't think this is the right way to do it... > > > My PowerBook is too old for X, but I can anyway start to make some > Carbonization "in blindo". There are a few things that must be > rewritten. For the most part, if you have 9.0, which works on most PPC PowerBooks anyway, then you can get the latest CarbonLib SDK and if you get your code to work linking to CarbonLib rather than InterfaceLib, then you are pretty much done on X as well. So even if you don't have X you don't have to work totally blind. I think even if you have a 68K PowerBook, you can run 8.6 and some version of CarbonLib, but I don't know any of the details of this. Jim _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham ji...@ap... Developer Tools - gdb |
From: Mats B. <ma...@pr...> - 2001-10-21 17:45:59
|
Jim Ingham wrote: > > On Saturday, October 20, 2001, at 03:19 AM, Mats Bengtsson wrote: > > No, it doesn't "hijack the event loop completely". It sets the function > that the Tcl event loop calls to convert a native event to a Tcl event. > IIRC (Bruce and I talked about this when he first did QTTcl, but it has > been a while...) you look at the events on the stream, and if you get a > "Play Movie" type event you handle it specially, and otherwise you send > it on to the function that was in place beforehand (TkMacConvertEvent). > Intercept is perhaps a better word for it. My point is that it stops other extensions from doing the same thing. > It would be much cleaner to have windows or subwindows register special > handlers for events at the native level, than to have to re-route the > whole event conversion mechanism. Another way to do this is to rely on Agree. Like WinProc in Win32, much better. > the Handler chain mechanism in Carbon Events, and so any event that the > Tk event converter doesn't recognize just gets sent up the chain, and > you will have to register a Carbon Event handler to deal with it. > Or perhaps the other way around, first low-level QT events etc., and then dispatch them to Tk. The Win32 code in QuickTimeTcl works like this. QT docs say that *all* events shall go through the "Is Player Event" handler, at least the Pre-Carbon docs. > I think something like this is what Jack needs as well. I need to take > a look at QTTcl again, figure out what things you need to do, and see if > I can come up with a good solution for you. I definitely want to get > this working, QTTcl is a VERY cool extension. But I never did like the > way it worked before, since it meant that you had to get your hands on > everybodies events to do something that was specific to your window... > Agree, it's terrible. > I want to get a better answer to the "how do I build any extensions at > all" question first, then I will look at this. However, if you want to > give it a try in the meantime, you are more than welcome. > My PowerBook is too old for X, but I can anyway start to make some Carbonization "in blindo". There are a few things that must be rewritten. /Mats |
From: Ralph H. <rh...@bm...> - 2001-10-21 02:54:29
|
I know it's been done before, but I'd like to extend a big thank-you to James Ingham and Daniel Steffen for keeping the faith in Tcl. I have resurrected my Tcl code and got my LEGO Mindstorms add-on working on a Mac too! In case anyone is interested, I was able to get my old Mac6100/60 working with my LEGO Mindstorms system by using the Serial Port OSAX 1.2 and a copy of Apple's Serial Tool. It's really slow, and really ugly because I can't use filevents. I have to poll the port using a procedure that is fired as the result of an "after" even, but it works! I know there must be an easier way to do this eventually but I'm convinced now that port or device access should be done via the channel architecture. The fact that /dev/ttyx looks like a file on Unix systems has hobbled the progress of port access for cross-platform Tcl applications for too long... I'll post a URL to my website that gives the details. I'm pretty proud of the fact that the same script runs on Mac/Win/Linux machines with minimal platform-specific code... Cheers, Ralph Hempel |
From: Jim I. <ji...@ap...> - 2001-10-20 18:00:40
|
On Saturday, October 20, 2001, at 03:19 AM, Mats Bengtsson wrote: > > Jim Ingham wrote: >> ... I bet once you get it built your troubles will only be >> beginning, since the Mac OS X event loop and the Mac event loop and the >> Unix event loops are all totally different... Jack Jensen and I have >> discussed this a little bit, but we haven't reached any firm >> conclusions > > Don't know how the Carbon event loop works, but for QuickTimeTcl I > need a hook to the Mac event loop for processing movie playback etc. > Now this is 'Tcl_MacSetEventProc', but I think it hijacks the > event loop completely. Perhaps it would be good to allow for > more than one extension to get a hook into the mac event loop. > Probably you already thought of this. Just wanted to remind you. No, it doesn't "hijack the event loop completely". It sets the function that the Tcl event loop calls to convert a native event to a Tcl event. IIRC (Bruce and I talked about this when he first did QTTcl, but it has been a while...) you look at the events on the stream, and if you get a "Play Movie" type event you handle it specially, and otherwise you send it on to the function that was in place beforehand (TkMacConvertEvent). It would be much cleaner to have windows or subwindows register special handlers for events at the native level, than to have to re-route the whole event conversion mechanism. Another way to do this is to rely on the Handler chain mechanism in Carbon Events, and so any event that the Tk event converter doesn't recognize just gets sent up the chain, and you will have to register a Carbon Event handler to deal with it. I think something like this is what Jack needs as well. I need to take a look at QTTcl again, figure out what things you need to do, and see if I can come up with a good solution for you. I definitely want to get this working, QTTcl is a VERY cool extension. But I never did like the way it worked before, since it meant that you had to get your hands on everybodies events to do something that was specific to your window... I want to get a better answer to the "how do I build any extensions at all" question first, then I will look at this. However, if you want to give it a try in the meantime, you are more than welcome. Jim > > /Mats > > PS: For QuickTimeTcl on Windows I use the Win32 native event loop, > emulated mac events, and Tk's event loop. Just love to get > one more event loop to deal with. > > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham ji...@ap... Developer Tools - gdb |
From: Mats B. <ma...@pr...> - 2001-10-20 10:18:50
|
Jim Ingham wrote: > ... I bet once you get it built your troubles will only be > beginning, since the Mac OS X event loop and the Mac event loop and the > Unix event loops are all totally different... Jack Jensen and I have > discussed this a little bit, but we haven't reached any firm conclusions Don't know how the Carbon event loop works, but for QuickTimeTcl I need a hook to the Mac event loop for processing movie playback etc. Now this is 'Tcl_MacSetEventProc', but I think it hijacks the event loop completely. Perhaps it would be good to allow for more than one extension to get a hook into the mac event loop. Probably you already thought of this. Just wanted to remind you. /Mats PS: For QuickTimeTcl on Windows I use the Win32 native event loop, emulated mac events, and Tk's event loop. Just love to get one more event loop to deal with. |
From: Jim I. <ji...@ap...> - 2001-10-20 00:49:13
|
Jack, I would get the installation location from -prefix, and stick the include files there (defaulting for now to /usr/local). It doesn't matter so much where they go, because the real key is to reference the location from the tclConfig.sh. People are used to having to do point configure for extensions at "the directory containing tclConfig.sh", though the config scripts will try to find it in a variety of unix'y places if you don't tell configure where the thing is. So as long as you can find that, and provided I can properly construct the Mac OS X version, we should be able to get you to all the other bits from there, and tell you all the proper compile options, et cetera, et cetera, and et cetera. That is why the key bit of work is to make tclConfig.sh and tkConfig.sh correct, and to make it easy for extension developers to make correct *Config.sh files for their extensions as well... I guess this latter bit is not so useful for you, though if you don't already use tclConfig.sh for your TkInter builds, you might want to think about it, it is quite useful. Jim On Friday, October 19, 2001, at 01:53 PM, Jack Jansen wrote: > > Recently, Jim Ingham <ji...@ap...> said: >> Jack, >> >> For Carbon, Apple distributed "flat headers" along with the Frameworks. >> So, in some standard place they put >> headers that just routed the standard include over to the framework >> style include. So you would have a tcl.h that just includes >> <Tcl/tcl.h>. > > Ah, interesting one! Then you would compile with -Ixxxx/FlatTcl > -framework Tcl. The only question is: where should xxxx be, so that > it's easily distributed with a Tcl distribution. If xxx is > /Library/Frameworks/Tcl.framework/etcetcetc it sort of defeats the > point... > -- > Jack Jansen | ++++ stop the execution of Mumia > Abu-Jamal ++++ > Jac...@or... | ++++ if you agree copy these lines to your > sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg- > l/sigaction.htm > -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Jack J. <ja...@or...> - 2001-10-19 20:54:53
|
Recently, Jim Ingham <ji...@ap...> said: > Jack, > > For Carbon, Apple distributed "flat headers" along with the Frameworks. > So, in some standard place they put > headers that just routed the standard include over to the framework > style include. So you would have a tcl.h that just includes <Tcl/tcl.h>. Ah, interesting one! Then you would compile with -Ixxxx/FlatTcl -framework Tcl. The only question is: where should xxxx be, so that it's easily distributed with a Tcl distribution. If xxx is /Library/Frameworks/Tcl.framework/etcetcetc it sort of defeats the point... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jac...@or... | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm |
From: Daniel A. S. <st...@ic...> - 2001-10-19 19:05:50
|
Jim, At 10:38 -0700 on 19/10/01, Jim Ingham wrote: >For Carbon, Apple distributed "flat headers" along with the >Frameworks. So, in some standard place they put >headers that just routed the standard include over to the framework >style include. So you would have a tcl.h that just includes ><Tcl/tcl.h>. > >Another way to go? > one option is indeed to put special copies of tcl.h and friends into /usr/include (which as you mention would just #include their framework equivalents). then building with e.g. -F ~/Library/Tcl -framework Tcl will just work (/usr/include is included by default no?) However makefiles not using TEA and expecting a standard /usr/include/tcl.h and -ltcl to map to /usr/lib/libtcl.dylib won't be happy anymore. The latter could be fixed with a symbolic link, but what about include files? One solution would be to specify a constant like #define USE_TCL_FRAMEWORK in tclConfig.sh that signals the use of <Tcl/*> style includes for TEA compliant builds, and put modified copies of tcl.h et al. into /usr/include that have a block like #ifdef USE_TCL_FRAMEWORK #include <Tcl/tcl.h> #else ... standard tcl.h ... #endif prepended, which should be easy to do with sed/awk/perl in a PBX shell script phase. then non-TEA makefiles should still work fine. (e.g. one infamous example for this would be TclX, I had a bad enough time already getting it to build with the current setup where SCRIPT_LIBRARY isn't inside /usr like it expects...) 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/> |
From: Tony L. <to...@me...> - 2001-10-19 18:42:25
|
While messing around with Tkinter, I'm having similar problems: Without adding any MacOSX specific code to Tkinter, the window Tk creates never responds to anything. I tried adding what I thought was the relevant code from tkMacOSXAppInit.c(*), and that didn't fix it... So, I tried compiling tkMacOSXAppInit.c alone to see if my problems were in how I was compiling the stuff - basically just did cc tkMacOSXAppInit.c -o a.out with a lot of -I's and -framework's And I got the same behavior! The window did not respond to events! Which leads me to wonder if I have to make a .app and not a plain binary. Jim, does that sound correct? Would the application need to be a .app? -Tony p.s. Your tk.h and tcl.h plan sounds good to me. (*) The code I added was: Tk_MacOSXSetupTkNotifier(); before Tcl_Init and TkMacOSXInitAppleEvents(v->interp); TkMacOSXInitMenus(v->interp); Tcl_CreateInterp > >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. > >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? -- |
From: Jim I. <ji...@ap...> - 2001-10-19 17:44:49
|
Jack, For Carbon, Apple distributed "flat headers" along with the Frameworks. So, in some standard place they put headers that just routed the standard include over to the framework style include. So you would have a tcl.h that just includes <Tcl/tcl.h>. Another way to go? Jim On Friday, October 19, 2001, at 05:49 AM, Jack Jansen wrote: > >>> 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, [...] > > For Python we have decided not to do this, at least, not yet. > > While Apple's "#include <Tcl/Tcl.h>" framework solution is really > elegant it > is also completely private to MacOSX (before I get thrashed, okay, > okay, it > probably comes from NeXT:-). > > Unless you can convince the whole Tcl/Tk world to switch to the > Tcl/Tcl.h > convention (and preferrably retroactively, say about 5 years ago:-) you > will > forever haunt the Tcl/Tk community with extensions that were created on > OSX > and won't compile on anything else, or the other way around. > > While the Tcl/Tcl.h convention is really elegant in that it forestalls > name > clashes in header files, given the fact that most of the software out > there > uses unadorned include files I think apple should add a > "-compat-framework" > option or some such that would allow #include "Tcl.h" to work, giving > compatibility at the expense of potential name clashes. > -- > Jack Jansen | ++++ stop the execution of Mumia > Abu-Jamal ++++ > Jac...@or... | ++++ if you agree copy these lines to your > sig ++++ > www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg- > l/sigaction.htm > > > > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Jim I. <ji...@ap...> - 2001-10-19 17:39:36
|
Marc-Antoine, On Friday, October 19, 2001, at 05:27 AM, Marc-Antoine Parent wrote: >>> 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. > > I agree with you that the Darwin and MacOSX Tcl/Tk are different > beasts, and do not need to use the same mechanisms. > This is precisely why I believe we need to "burden" the unix build > mechanisms, such as TkConfig.sh, with the dylib vs framework > distinction. Indeed, the problem goes beyond building the Tcl/Tk > frameworks from the command line or ProjectBuilder; all unix clients of > the Tcl/Tk code (like Mozart, and Python, and...) need to change, not > only their compile and link flags (handled by tkConfig.sh) but also > their #include directives to adjust to an (optionally) framework-based > Tcl/Tk... We cannot expect all these to use PB. That means that the > Tcl/Tk framework must expose its frameworkness to the unix world. This > is why I made the half-joke, half daydream that the notion of > framework, and what it entails for the build process, will eventually > have to make it all the way to autoconf! (I understand why Wilfredo > Sanchez was reluctant. But I think that frameworks are a Good Idea in > terms of what they allow for linking, and the *n*x community at large > can benefit.) They are nice in general, but they are particularly nice for Tcl & Co. Here you often have the problem of keeping together a shared library and some Tcl script files, and being able to find both. The CFBundle API's mean that if the linker can find the shared library, you can unerringly find the correct script files in the framework. This leads to a great simplification in the work that tcl_findLibrary has to do. > > So, formally, my short-term proposal is to add > "TK_DARWIN_FRAMEWORK=true" to the tkConfig.sh (idem for tcl, of course) > so that we can test for this flag in the mozart codebase, and choose > the #include directive accordingly. I think you misunderstood me. The question I was debating internally was not whether to generate a Framework-ified tkConfig.sh, etc, but rather whether to use tcl.m4 and configure.in to generate the appropriate entries in the file, or to provide some post-processing in the header copy phase on the MacOS X side to fix up these files. The former is a better engineering solution, but a lot more work, and I don't think that the benefits outweigh the cost right now - I have a lot of other things to work on at the same time. If someone else wants to take this up, though, that would be really great. I definitely agree that the TEA-style config scripts should be generated in such a way as to be useful for the Tcl and Tk frameworks. Jim -- Jim Ingham ji...@ap... Developer Tools - gdb Apple Computer |
From: Jack J. <ja...@or...> - 2001-10-19 12:51:02
|
> > 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, [...] For Python we have decided not to do this, at least, not yet. While Apple's "#include <Tcl/Tcl.h>" framework solution is really elegant it is also completely private to MacOSX (before I get thrashed, okay, okay, it probably comes from NeXT:-). Unless you can convince the whole Tcl/Tk world to switch to the Tcl/Tcl.h convention (and preferrably retroactively, say about 5 years ago:-) you will forever haunt the Tcl/Tk community with extensions that were created on OSX and won't compile on anything else, or the other way around. While the Tcl/Tcl.h convention is really elegant in that it forestalls name clashes in header files, given the fact that most of the software out there uses unadorned include files I think apple should add a "-compat-framework" option or some such that would allow #include "Tcl.h" to work, giving compatibility at the expense of potential name clashes. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jac...@or... | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm |
From: Marc-Antoine P. <map...@ac...> - 2001-10-19 12:27:42
|
>> 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. I agree with you that the Darwin and MacOSX Tcl/Tk are different beasts, and do not need to use the same mechanisms. This is precisely why I believe we need to "burden" the unix build mechanisms, such as TkConfig.sh, with the dylib vs framework distinction. Indeed, the problem goes beyond building the Tcl/Tk frameworks from the command line or ProjectBuilder; all unix clients of the Tcl/Tk code (like Mozart, and Python, and...) need to change, not only their compile and link flags (handled by tkConfig.sh) but also their #include directives to adjust to an (optionally) framework-based Tcl/Tk... We cannot expect all these to use PB. That means that the Tcl/Tk framework must expose its frameworkness to the unix world. This is why I made the half-joke, half daydream that the notion of framework, and what it entails for the build process, will eventually have to make it all the way to autoconf! (I understand why Wilfredo Sanchez was reluctant. But I think that frameworks are a Good Idea in terms of what they allow for linking, and the *n*x community at large can benefit.) So, formally, my short-term proposal is to add "TK_DARWIN_FRAMEWORK=true" to the tkConfig.sh (idem for tcl, of course) so that we can test for this flag in the mozart codebase, and choose the #include directive accordingly. Enjoy! Marc-Antoine Parent |
From: Daniel A. S. <st...@ic...> - 2001-10-19 06:25:27
|
[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article <3BCF8968.80B10EFA@ActiveState.com>, Jeff Hobbs <JeffH@ActiveState.com> wrote: > You can get the candidate release at: > > http://sourceforge.net/project/showfiles.php?group_id=10894 > > in the 8.3.4 Release Candidate section. I have added installers for the mac binary build to the 8.3.4 Release Candidate section on sourceforge. report problems with those to me <mailto:da...@us...> and not Jeff... Cheers, Daniel |
From: Jim I. <ji...@ap...> - 2001-10-19 05:12:41
|
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 |