From savage@2xtreme.net Wed Oct 7 07:20:32 1998 From: savage@2xtreme.net (Bob Savage) Date: Tue, 6 Oct 1998 23:20:32 -0700 Subject: [Pythonmac-SIG] pythonmac & GUI Message-ID: Hi, I have been slowly learning Python, but have yet to do anything with a GUI. I tried Tkinter a few times, but it doesn't seem to work reliably for me. I tried running the 'Hello GUI world' code from the Lutz tome, and I ended up not being able to quit from the Python IDE (the menubar changes to reflect the mini app, but 'quit' does not work, so all I can do is force quit??) The same thing happened on two different computers, BTW. I looked at the "FrameWork.py" file and the documentation in the Mac addendum to the reference, but I don't think I can do anything with that without at least one example (if someone has an example, even a small one, I would love to see it). That leaves learning the Macintosh Toolbox and the bindings offered in the various Python modules. I would prefer not doing that because I really want to hop on MacOS X as soon as possible (I'll be getting MacOS X Server as soon as it becomes available -- I really need the stability, for one thing) so I am leary of learning APIs that are about to go away. (Are there plans for carrying Python forward onto MacOS X / X server (Rhapsody)?) At this point it seems like my best bet is just wait and not get tied to a GUI framework until something or another firms up (Does someone have a better suggestion?) Thanks for the help, Bob Bob Savage _________________________________________________________________________ e^mail -> savage@2xtreme.net _________________________________________________________________________ From Jack.Jansen@cwi.nl Wed Oct 7 09:57:02 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 07 Oct 1998 10:57:02 +0200 Subject: [Pythonmac-SIG] pythonmac & GUI In-Reply-To: Message by Bob Savage , Tue, 6 Oct 1998 23:20:32 -0700 , Message-ID: > I looked at the "FrameWork.py" file and the documentation in the Mac > addendum to the reference, but I don't think I can do anything with that > without at least one example (if someone has an example, even a small one, > I would love to see it). The examples in the Mac:Demo folder use FrameWork. PICTbrowse is a simple one, the waste examples are a bit more involved. I think some of the others use FrameWork as well. > That leaves learning the Macintosh Toolbox and the bindings offered in the > various Python modules. I would prefer not doing that because I really want > to hop on MacOS X as soon as possible (I'll be getting MacOS X Server as > soon as it becomes available -- I really need the stability, for one thing) > so I am leary of learning APIs that are about to go away. (Are there plans > for carrying Python forward onto MacOS X / X server (Rhapsody)?) Rhapsody/MacOS X Server is probably a station that I'll skip, but I'll happily accept donated code. On the other hand: as far as I understand the standard unix Python might run under that. The real MacOS X is a different story, of course. I've already used the carbon dater on Python, and it seems the only real problems are where I expected them, in the low-level event loop. Python already uses accessor functions in stead of straight access to locore and os object internals, so we should be fine there. You never know what pops up along the way, though. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From wolfgang@amadeus.m.eunet.de Fri Oct 9 20:05:43 1998 From: wolfgang@amadeus.m.eunet.de (Wolfgang Keller) Date: Fri, 9 Oct 1998 21:05:43 +0200 Subject: [Pythonmac-SIG] PythonIDE - browser problem with Framework.py? Message-ID: It seems to me that any time I try to open Framework.py in the module browser of the PythonIDE, the window is entirely messed up. Has anyone else experienced similar problems? BTW: How about a possibility to structure code in the editor window to make it easier to handle larger scripts/programs? A combination of two windows would be nice; one to list all classes/methods and one for the source code of the actually selected class/method. A sourcecode outliner for larger pieces of code (like in Frontier) would also be very useful imho. The basic list element is already there in the module browser, how much work would it be to add the rest? Regards, Wolfgang Keller Zu Risiken und Nebenwirkungen von Junkmail lesen Sie de.admin.net-abuse.mail und fragen sie Ihren Postmaster oder Provider From just@letterror.com Sun Oct 11 17:03:08 1998 From: just@letterror.com (Just van Rossum) Date: Sun, 11 Oct 1998 18:03:08 +0200 Subject: [Pythonmac-SIG] PythonIDE - browser problem with Framework.py? In-Reply-To: Message-ID: At 9:05 PM +0200 10/9/98, Wolfgang Keller wrote: >It seems to me that any time I try to open Framework.py in the module >browser of the PythonIDE, the window is entirely messed up. Has anyone else >experienced similar problems? Yes, I'm sorry it's not on the "known bugs" list. The browser widget uses the Apple List Manager, which screws up badly if you feed it more than 32k of data. >BTW: How about a possibility to structure code in the editor window to make >it easier to handle larger scripts/programs? A combination of two windows >would be nice; one to list all classes/methods and one for the source code >of the actually selected class/method. You do know of the little popup menu next to the line number field? >A sourcecode outliner for larger >pieces of code (like in Frontier) would also be very useful imho. That has been my original plan from the start. It's just really hard to implement nicely. Just From kantel@mpiwg-berlin.mpg.de Fri Oct 16 10:00:23 1998 From: kantel@mpiwg-berlin.mpg.de (Joerg Kantel) Date: Fri, 16 Oct 1998 11:00:23 +0200 Subject: [Pythonmac-SIG] [Q]: Is PyGraph running on MacPython? Message-ID: Dear Python Users, maybe it's a silly question. But browsing through the Python-Site I found informations about a package called PyGraph. And it is exactly that what I need for visualising research datas. Therefore my question: Is there a port to MacPython available? Or exists a aequivalent package on the Mac? Thanks for your help J"org -- ------------------------------------------------------------------------------ J"org Kantel email: kantel@mpiwg-berlin.mpg.de Max Planck Institute for the History of Science phone: +4930-22667-220 Wilhelmstr. 44 fax: +4930-22667-299 D-10117 Berlin http://www.mpiwg-berlin.mpg.de/staff/kantel/kantel.html ------------------------------------------------------------------------------ From Jack.Jansen@cwi.nl Fri Oct 16 10:57:23 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 16 Oct 1998 11:57:23 +0200 Subject: [Pythonmac-SIG] NumPy and the LLNL distribution Message-ID: Folks, is anyone willing to adopt the Mac version of Numeric Python (and possibly the rest of the LLNL distrbution, of which a new version was just announced)? I'm rather busy at the moment, and since I don't use the numerics stuff myself it would be helpful if I could offload it to someone else. The NumPy shipped with macpython is still at release 1.0b3, which the LLNL distribution is now at 1.6... Another question is whether anyone is actually using it. If you do so please tell me, otherwise I guess I'll just drop the numerics package (unless someone offers to maintain it, of course). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From just@letterror.com Fri Oct 16 11:42:51 1998 From: just@letterror.com (Just van Rossum) Date: Fri, 16 Oct 1998 12:42:51 +0200 Subject: [Pythonmac-SIG] NumPy and the LLNL distribution In-Reply-To: Message-ID: At 11:57 AM +0200 10/16/98, Jack Jansen wrote: >Folks, >is anyone willing to adopt the Mac version of Numeric Python (and possibly >the >rest of the LLNL distrbution, of which a new version was just announced)? > >I'm rather busy at the moment, and since I don't use the numerics stuff >myself >it would be helpful if I could offload it to someone else. The NumPy shipped >with macpython is still at release 1.0b3, which the LLNL distribution is now >at 1.6... > >Another question is whether anyone is actually using it. If you do so please >tell me, otherwise I guess I'll just drop the numerics package (unless >someone >offers to maintain it, of course). I use NumPy a lot! I've never looked at the sources, so I'm not sure if I'm capable of maintaining a Mac port. But I'd sure be willing to help since I'm getting to a point where I couldn't live without it. Just From patrick@swdev.com Fri Oct 16 17:05:01 1998 From: patrick@swdev.com (Patrick Curtain) Date: Fri, 16 Oct 1998 08:05:01 -0800 Subject: [Pythonmac-SIG] NumPy and the LLNL distribution References: Message-ID: <36276EA4.158D4CD0@swdev.com> Howdy all! Just van Rossum wrote: > I use NumPy a lot! I've never looked at the sources, so I'm not sure if I'm > capable of maintaining a Mac port. But I'd sure be willing to help since > I'm getting to a point where I couldn't live without it. I don't even have a compiler installed anymore, but I've been doing c/c++ on the mac for years. If I can help, let me know! --p ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Patrick Curtain, Husband & Father (I also write Software) patrick@swdev.com, http://www.swdev.com/ From managan@llnl.gov Fri Oct 16 21:27:22 1998 From: managan@llnl.gov (Rob Managan) Date: Fri, 16 Oct 1998 13:27:22 -0700 Subject: [Pythonmac-SIG] NumPy and Graphics issues Message-ID: I have played with the NumPy module off and on. It is real easy to compile. In fact I just did Numerical; a few minutes of copying files and <3 minutes to compile. I have shipped previous versions to a few people but don't have an ftp site available to me. (Seems that I have a problem with the CFM68K version and the definition of hypot, no time to track it down and most use PPC) At this point my set up is to use the LLNL directory structure and add a Mac folder that holds all the CW projects and shared libraries. Then you add the The RNG module even has some source code to get the current time for a random seed that I contributed. Summary: I have CW projects for Numerical (NumPy), PyPDB, and RNG. I also have one for PyOpenGL but it doesn't work with Tk yet. Anyone want to port the ToGL widget? Anyone want to take up the project of replacing the lapack_lite in the distribution with the full Lapack sources? They are available with CW projects for the Mac. ------- GRAPHICS ------- Back to Joerg Kantel's question. PyGraph is not running on the Mac since the underlying graphics library Gist has not been ported. That will be a major effort I'm afraid and one I can't undertake. I can offer a plplot module as an alternative. I am sure someone could take that and weave it into PyGraph with some Python programming. Mainly that means translating Gist calls into plplot calls. You might also want to implement a way to tell the graphics code whether you are using Gist or plplot (They may have the hooks for this as I recall since Narcisse is an option as well.) Final question. Is it worth trying to get a stuffit archive for the Mac folder included in the distribution? The down side is that you would have to recompile it and most won't have CodeWarrior. Or would it just help to get copies to Jack and/or Just and get the the latest copies distributed from their sites?? *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan mailto://managan@llnl.gov LLNL ph: 925-423-0903 P.O. Box 808, L-183 FAX: 925-423-5804 Livermore, CA 94551-0808 From red_bird@macfreak.com Sun Oct 18 15:17:31 1998 From: red_bird@macfreak.com (Gordon Worley) Date: Sun, 18 Oct 1998 14:17:31 +0000 Subject: [Pythonmac-SIG] RandomArray problem... Message-ID: Has anyone else had this problem: When the RandomArray module of NumPy is imported, it prints a few letters seperated by commas, "ABORT" followed by some text and more letters, and then quits Python. The problem seems to be happening when the module is loaded, because in my program I have tried loading the module both at the beginning of the program and at the time of use, resulting in Python quiting when the module is loaded. Is this a bug in NumPy or have I simply got Python set-up wrong? ________________________________________ Red Bird Island Productions Gordon Worley (red_bird) http://members.xoom.com/red_bird/ mailto:red_bird@macfreak.com From just@letterror.com Mon Oct 19 12:50:37 1998 From: just@letterror.com (Just van Rossum) Date: Mon, 19 Oct 1998 13:50:37 +0200 Subject: [Pythonmac-SIG] RandomArray problem... In-Reply-To: Message-ID: At 2:17 PM +0000 10/18/98, Gordon Worley wrote: > Has anyone else had this problem: When the RandomArray module of >NumPy is imported, it prints a few letters seperated by commas, "ABORT" >followed by some text and more letters, and then quits Python. The problem >seems to be happening when the module is loaded, because in my program I >have tried loading the module both at the beginning of the program and at >the time of use, resulting in Python quiting when the module is loaded. Is >this a bug in NumPy or have I simply got Python set-up wrong? It is a bug in NumPy indeed. I've reported it to the NumPy folks, and suggested a solution. It's a problem with the seed() function. Try to replace it with this: ArgumentError = "ArgumentError" def seed(x=0,y=0): if type (x) != IntType or type (y) != IntType : raise ArgumentError, "seed requires integer arguments." if x == y == 0: import time t = time.time() / 100.0 x = int(t) y = int((t-int(t))*1000000) ranlib.set_seeds(x,y) return seed() It seems to work for NumPy 1.5 (or is that 1.6?) but I'm not sure if this works for the version currently in the MacPython distribution. Let me know if it doesn't, I could send you the new stuff. Just From peter.sommerfeld@gmx.de Wed Oct 21 23:17:57 1998 From: peter.sommerfeld@gmx.de (Peter Sommerfeld) Date: Thu, 22 Oct 1998 00:17:57 +0200 Subject: [Pythonmac-SIG] mac event loop Message-ID: <199810212218.SAA28219@python.org> For various reasons I've made my event loop from scratch an do not use FrameWork.py. As expected I've got some problems :) (1) I would like to override the std zoom in / zoom out behavior for something like a full screen mode. According to "Inside Macintosh" I have to change the stdState of the WStateData structure in the dataHandle field of the window record. in PASCAL: (Toolbox Essentials 4-55) WSTateDataHandle(WindowPeek(thisWindow)^.dataHandle)^^stdState := zoomRect Can that be done in python and if so, how ? If not I can use SizeWindow() with an flag but I prefer to avoid that way. (2) The multiple event loop problem bites me too :). I normally use JvR's IDE and have to update it's windows manually after running my application. This is annoying on the long run. May be I could check for the wid attribute of the frontmost window like FrameWork.py but I understood that there are other loops/windows too. Is there or will be there a generalized way to handle this ? (3) I (presently) don't think that my application will need multi threading. Is there a need to implement async events anyway ? (I dont have any clue about multi threading on Mac/Python up to now :) (4) My last point is a suggestion. It is recommended by Apple to use menuID's from 1 to 235 for application *submenus* and each other number > 128 for menus (Toolbox Essentials 3-44). When I used 1 I got a conflict with the IDE or python-out. I didn't check submenus up to now but I think there is a need for two funktions like GetMenuID() -> menuID GetSubMenuID() -> submenuID Comments, ideas, suggestions ? thanks Peter PS: Thanks a lot to JvR for his great IDE ! I can hardly imagine to do all that work without it. I don't use the debugger often (because print is really easy to use in python) but *IF* I use it, it is really needed ! From Jack.Jansen@cwi.nl Thu Oct 22 10:39:59 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 22 Oct 1998 11:39:59 +0200 Subject: [Pythonmac-SIG] mac event loop In-Reply-To: Message by "Peter Sommerfeld" , Thu, 22 Oct 1998 00:17:57 +0200 , <199810212218.SAA28219@python.org> Message-ID: > > For various reasons I've made my event loop from scratch an do not use > FrameWork.py. As expected I've got some problems :) > > (1) I would like to override the std zoom in / zoom out behavior for > something like a full screen mode. According to "Inside Macintosh" I have to > change the stdState of the WStateData structure in the dataHandle field of > the window record. > > in PASCAL: (Toolbox Essentials 4-55) > > WSTateDataHandle(WindowPeek(thisWindow)^.dataHandle)^^stdState := > zoomRect > > Can that be done in python and if so, how ? If not I can use SizeWindow() > with an flag but I prefer to avoid that way. You cannot get at the dataHandle attribute currently. But, note that you don't need this to implement zooming: ZoomWindow() is usually enough. You only need to get at the stdState structure if you want to maximized state to be something different than (almost) the whole screen. > (2) The multiple event loop problem bites me too :). I normally use JvR's > IDE and have to update it's windows manually after running my application. > This is annoying on the long run. May be I could check for the wid attribute > of the frontmost window like FrameWork.py but I understood that there are > other loops/windows too. Is there or will be there a generalized way to > handle this ? Passing your event to MacOS.HandleEvent() when you notice that the event isn't for you will do part of the work: it will at least update the stdio window and do cmd-. processing if you haven't disabled it. There may be something similar for IDE, but I'll leave it to Just to answer that. A generalized way to do this is actually pretty simple to implement, but I haven't gotten around to it yet. A python module EventLoops would be needed, with an API something like register(identity, myeventhandler) unregister(identity) handle_event(identity, event) Where identity is an opaque object identifying the module/object with a mainloop. In each mainloop you handle all the events that are yours, and pass the rest to handle_event. Handle_event will then call the myeventhandler routines of all the other mainloop objects (except for the one of the module passing the event in, hence the identity object) until one returns non-zero, signifying the event is fully handled. > (3) I (presently) don't think that my application will need multi threading. > Is there a need to implement async events anyway ? (I dont have any clue > about multi threading on Mac/Python up to now :) It depends. For my applications a combination of select() and WaitNextEvent() usually does the trick. You can integrate the select stuff into your mainloop by adding an interface setiocallback(selectableobject, callback), and in your mainloop calling select() when WaitNextEvent returns. You can also change the timeout to WNE depending on whether or not any I/O objects are being waited on. Idle routines for things like pushing quicktime movies along can be implemented in the same way. > > (4) My last point is a suggestion. It is recommended by Apple to use > menuID's from 1 to 235 for application *submenus* and each other number > > 128 for menus (Toolbox Essentials 3-44). When I used 1 I got a conflict with > the IDE or python-out. I didn't check submenus up to now but I think there > is a need for two funktions like > > GetMenuID() -> menuID > GetSubMenuID() -> submenuID This sounds like a good idea, but I'm unsure where to add the methods. FrameWork.py? Also, does anyone _really_ understand the section in IM (menu manager, page 3-44)? I get the impression that the restriction that main menus should have IDs > 128 only holds for menus read from resources, and the description of NewMenu also doesn't mention the >128 restriction... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From billpy@mousa.demon.co.uk Thu Oct 22 14:33:58 1998 From: billpy@mousa.demon.co.uk (Bill Bedford) Date: Thu, 22 Oct 1998 14:33:58 +0100 Subject: [Pythonmac-SIG] mac event loop In-Reply-To: References: Message by "Peter Sommerfeld" , Thu, 22 Oct 1998 00:17:57 +0200 , <199810212218.SAA28219@python.org> Message-ID: <538609761700033530678@mousa.demon.co.uk> At 11:39 am +0200 22/10/98, Jack Jansen wrote: >> >> For various reasons I've made my event loop from scratch an do not use >> FrameWork.py. As expected I've got some problems :) >> >> (1) I would like to override the std zoom in / zoom out behavior for >> something like a full screen mode. According to "Inside Macintosh" I have to >> change the stdState of the WStateData structure in the dataHandle field of >> the window record. >> >> in PASCAL: (Toolbox Essentials 4-55) >> >> WSTateDataHandle(WindowPeek(thisWindow)^.dataHandle)^^stdState :>> zoomRect >> >> Can that be done in python and if so, how ? If not I can use SizeWindow() >> with an flag but I prefer to avoid that way. > >You cannot get at the dataHandle attribute currently. But, note that you >don't >need this to implement zooming: ZoomWindow() is usually enough. You only need >to get at the stdState structure if you want to maximized state to be >something different than (almost) the whole screen. But you should be able to save the userstate so that the window opens as the user left it. >> (4) My last point is a suggestion. It is recommended by Apple to use >> menuID's from 1 to 235 for application *submenus* and each other number > >> 128 for menus (Toolbox Essentials 3-44). When I used 1 I got a conflict with >> the IDE or python-out. I didn't check submenus up to now but I think there >> is a need for two funktions like >> >> GetMenuID() -> menuID >> GetSubMenuID() -> submenuID > >This sounds like a good idea, but I'm unsure where to add the methods. >FrameWork.py? It's not necessary you call InsertMenu(after) to actually draw the menu. The int 'after' is: 0 if it is to be inserted at the end of the menu bar, a positive number if it is to be inserted among the existing menus, or -1 if it is to be a submenu. This allows, for instance, a menu to be on the menu bar in one screen and a submenu in another. > >Also, does anyone _really_ understand the section in IM (menu manager, page >3-44)? I get the impression that the restriction that main menus should have >IDs > 128 only holds for menus read from resources, and the description of >NewMenu also doesn't mention the >128 restriction... Yep, and poking about with Resedit in various apps it seems to more honored in the breach than the observation. PS. Jack, Writing this has forced me to look at my bFramework code, and get the submenus to work, I'll clean it up a bit and send you a copy in the next few days. -- Bill Bedford Owner Brit_Rail-L list for the history of railways in Britain Subscribe at autoshare@mousa.demon.co.uk From peter.sommerfeld@gmx.de Thu Oct 22 15:06:17 1998 From: peter.sommerfeld@gmx.de (Peter Sommerfeld) Date: Thu, 22 Oct 1998 16:06:17 +0200 Subject: [Pythonmac-SIG] Re: mac event loop Message-ID: <199810221407.KAA07139@python.org> > You cannot get at the dataHandle attribute currently. But, note that you don't > need this to implement zooming: ZoomWindow() is usually enough. You only need > to get at the stdState structure if you want to maximized state to be > something different than (almost) the whole screen. Yes, I've implemented the std behavior but it doesn't fullfill my requirements. Anyway, another way might be to reset termporarily the size of the grey region. Win.py supports GetGreyRegion(). Is there a way to set the grey region ? Hmm ..., I think presently the most easy way will be to use Size/MoveWindow() :) >Also, does anyone _really_ understand the section in IM (menu manager, page >3-44)? I get the impression that the restriction that main menus should have >IDs > 128 only holds for menus read from resources, and the description of >NewMenu also doesn't mention the >128 restriction... Probably you are correct. I'll report if anything is going wrong with submenu ID's > 232 (Haven't implemented submenus yet). >> GetMenuID() -> menuID >> GetSubMenuID() -> submenuID > >This sounds like a good idea, but I'm unsure where to add the methods. >FrameWork.py? A global GetMenuID() function could serve all involved menu handler. May be it should start with 256 to avoid conflicts with resource ID's. It's best location would be (Mac) Menu.py. If you put it into FramWork.py everybody has to load this module. This should better be avoided IMO. >> (3) I (presently) don't think that my application will need multi threading. >> Is there a need to implement async events anyway ? (I dont have any clue >> about multi threading on Mac/Python up to now :) >It depends. For my applications a combination of select() and WaitNextEvent() >usually does the trick. Sorry, there is a missunderstanding. My english isn't the best. What I would like to know is whether other eventloops *expect* me to handle async events. For instance: I later have to use Sockets (or mac TCP/IP, PPP) as well as AppleEvents. Is there any *need* to handle async events for this modules. Probably your answer is "It depends ..." :)) Presently I work on a semi-portable GUI and this will work well without threads. - Peter From Jack.Jansen@cwi.nl Thu Oct 22 15:27:31 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 22 Oct 1998 16:27:31 +0200 Subject: [Pythonmac-SIG] Re: mac event loop In-Reply-To: Message by "Peter Sommerfeld" , Thu, 22 Oct 1998 16:06:17 +0200 , <199810221407.KAA07139@python.org> Message-ID: > Yes, I've implemented the std behavior but it doesn't fullfill my > requirements. Anyway, another way might be to reset termporarily the size of > the grey region. Win.py supports GetGreyRegion(). Is there a way to set the > grey region ? Hmm ..., I think presently the most easy way will be to use > Size/MoveWindow() :) Hmm. Would it be good enough if I allowed you access to the dataHandle item as a handle? This is fairly easy to implement, and you could fill the handle yourself with the struct module (through it's data attribute). > A global GetMenuID() function could serve all involved menu handler. May be > it should start with 256 to avoid conflicts with resource ID's. It's best > location would be (Mac) Menu.py. If you put it into FramWork.py everybody > has to load this module. This should better be avoided IMO. Except that Menu.py is automatically generated, and I'd like to keep it that way. Actually, maybe we should add a module whose only job is to coordinate the various packages that use windows, events, menus, etc. This could contain the menuid stuff, the event loop stuff and possibly more. What do you all think? > Sorry, there is a missunderstanding. My english isn't the best. What I would > like to know is whether other eventloops *expect* me to handle async events. > For instance: I later have to use Sockets (or mac TCP/IP, PPP) as well as > AppleEvents. Is there any *need* to handle async events for this modules. > Probably your answer is "It depends ..." :)) I tend to think of the current mainloop as the important one, and the other mainloops get a little support (redraws, mainly), but that is all. I wouldn't worry too much about your mainloop having to handle async events for, say, the Tk mainloop. This doesn't really sound like decent programming practice. And, of course, if it'll ever happen we could always add hooks in the coordinatiojn module mentioned above... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From Jack.Jansen@cwi.nl Thu Oct 22 15:49:24 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 22 Oct 1998 16:49:24 +0200 Subject: [Pythonmac-SIG] Re: mac event loop In-Reply-To: Message by Jack Jansen , Thu, 22 Oct 1998 16:27:31 +0200 , Message-ID: Following up on myself... > Hmm. Would it be good enough if I allowed you access to the dataHandle item as > a handle? This is fairly easy to implement, and you could fill the handle > yourself with the struct module (through it's data attribute). Ok, I've added the accessor methods for the dataHandle (GetWindowDataHandle and SetWindowDataHandle), they'll be in the next version. However, I also noticed the accessor functions GetWindowUserState and GetWindowStandardState and the corresponding Set.... functions, maybe these are good enough for your purpose? They are already implemented in the current Win module, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From peter.sommerfeld@gmx.de Thu Oct 22 22:40:42 1998 From: peter.sommerfeld@gmx.de (Peter Sommerfeld) Date: Thu, 22 Oct 1998 23:40:42 +0200 Subject: [Pythonmac-SIG] Re: mac event loop Message-ID: <199810222202.SAA13191@python.org> Jack Jansen wrote: > However, I also noticed the accessor functions GetWindowUserState and > GetWindowStandardState and the corresponding Set.... functions, maybe these > are good enough for your purpose? They are already implemented in the current > Win module, Great, that's what I need :). Let me know the input/return parameter please. I wonder how I can get that info by myself. Up to now I haven't downloaded the source code because I have a somewhat outdated compiler (CW 8).The Win module of the std destribution is delivered as shared lib and the IDE does not list Get/SetWindowUserState(). Do I miss anything ? Probably I have to download the source ... > Actually, maybe we should add a module whose only job is to coordinate the > various packages that use windows, events, menus, etc. This could contain the > menuid stuff, the event loop stuff and possibly more. > What do you all think? I personally prefere to keep things together but automatic generation out of source files is actually a *very* strong argument. To use something like a glue.py is one good possibility. Another one might be to make a destinction between interface and implementation. The interface module than imports the automaticly generated implementation modules transparently. This would increase compiler independence too (not an issue presently :( May be the former is a solution for now and we should think about a better and more abstract interface for the long run :) Some considerations: The mac event loop is somewhat outdated, unneccesary complicated and inconsistent too. For instance: the BeginUpdate/EndUpdate and ZoomIn/ZoomOut logic can easily be hidden. This can be reduced in a more elaborated callback system to resized() and update() calls only. Another one:If resumed it depends on the time the user presses the mouse button whether a mouseUp event occurs or not. I don't expect that the carbon interface will change much on that all. The advantage of using mac calls directly is documentation and may be (?) more flexibility. But the python implementation is different anyway and probably most folks use FrameWork.py. FrameWork.py seems (to me!) to be too much highlevel and lowlevel at the same time. There is no need to face the user with any mac specific stuff like event records etc in Window, Menu or Application classes. To keep such classes clear of platform specific stuff will increase portability remarkable. But may be portability isn't that importand for others. So far ... Peter From Jack.Jansen@cwi.nl Fri Oct 23 10:40:28 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 23 Oct 1998 11:40:28 +0200 Subject: [Pythonmac-SIG] Re: mac event loop In-Reply-To: Message by "Peter Sommerfeld" , Thu, 22 Oct 1998 23:40:42 +0200 , <199810222202.SAA13191@python.org> Message-ID: > Great, that's what I need :). Let me know the input/return parameter please. > > I wonder how I can get that info by myself. Up to now I haven't downloaded > the source code because I have a somewhat outdated compiler (CW 8).The Win > module of the std destribution is delivered as shared lib and the IDE does > not list Get/SetWindowUserState(). Do I miss anything ? Probably I have to > download the source ... That's not necessary. For all the automatically generated modules the docstrings of the various methods show their calling convention. Together with Inside Mac or some oter source of information on what the call does this should give you enough information. The only problem is getting at the docstring: to get it for GetWindowUserState, for instance, you'll first have to create a Window object. I don't know of any way around this (does anyone else?). > The advantage of using mac calls directly is documentation and may be (?) > more > flexibility. But the python implementation is different anyway and probably > most folks use FrameWork.py. FrameWork.py seems (to me!) to be too much > highlevel > and lowlevel at the same time. FrameWork basically "happened", in stead of having been designed. Guido started it years ago, and since then I've been adding stuff as I needed it, and so did Just and a few other people. Still, I find that it's low-level enough and adaptable enough that I hardly ever write an event loop from scratch anymore. I'm still pretty angry with myself for starting from scratch once (for cmifed/grins, my main project), because in the long run it would have saved lots and lots of work if I had adapted FrameWork in stead. What would be nice if we had an alternative high-level framework, for instance by exporting metrowerks PowerPlant framework to Python. This is basically what Mark Hammond has done for MFC on Windows, and the result is that PythonWin programs often look pretty slick. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From peter.sommerfeld@gmx.de Fri Oct 23 12:05:27 1998 From: peter.sommerfeld@gmx.de (Peter Sommerfeld) Date: Fri, 23 Oct 1998 13:05:27 +0200 Subject: [Pythonmac-SIG] Re: mac event loop Message-ID: <199810231106.HAA20415@python.org> Jack Jansen wrote: > The only problem is getting at the docstring: to get it for > GetWindowUserState, for instance, you'll first have to create a Window > object. I don't know of any way around this (does anyone else?). Will check it out. Should be no problem at all. > Still, I find that it's low-level enough and adaptable enough that > I hardly ever write an event loop from scratch anymore. I'm still > pretty angry with myself for starting from scratch once > (for cmifed/grins, my main project), because in the long run it would > have saved lots and lots of work if I had adapted FrameWork in stead. Much work indeed. I'll see. For me it's at least a good opportunity to learn python and something more about the mac. Perfection is reached at the point of desaster ... > What would be nice if we had an alternative high-level framework, for > instance by exporting metrowerks PowerPlant framework to Python. This > is basically what Mark Hammond has done for MFC on Windows, and the > result is that PythonWin programs often look pretty slick. Agreed. If portability is an issue a cross-platform lib would do the job too. I would like to see wxWindows on the mac to check it out. Anyway, back to work ... Thanks a lot Peter From billb@mousa.demon.co.uk Fri Oct 23 17:57:09 1998 From: billb@mousa.demon.co.uk (Bill Bedford) Date: Fri, 23 Oct 1998 17:57:09 +0100 Subject: [Pythonmac-SIG] MPW Message-ID: <907421386860309889582@mousa.demon.co.uk> Some time ago various people were talking of trying to complie python under MPW. Has anyone done it yet? and would they like to share their experiences? -- Bill Bedford Owner Brit_Rail-L list for the history of railways in Britain Subscribe at autoshare@mousa.demon.co.uk From rmore@onramp.net Fri Oct 23 19:25:13 1998 From: rmore@onramp.net (Rod Morehead) Date: Fri, 23 Oct 1998 13:25:13 -0500 (CDT) Subject: [Pythonmac-SIG] MPW In-Reply-To: <907421386860309889582@mousa.demon.co.uk> References: <907421386860309889582@mousa.demon.co.uk> Message-ID: <13872.51721.642507.697448@ghostwheel> Bill Bedford writes: > Some time ago various people were talking of trying to complie python under > MPW. Has anyone done it yet? and would they like to share their experiences? I think one of the biggest problems right now is the lack of a GUSI to go with any recent MPW release. GUSI provides the networking/socket level stuff. Thanks, -- Rod From Jack.Jansen@cwi.nl Fri Oct 23 23:03:34 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sat, 24 Oct 1998 00:03:34 +0200 Subject: [Pythonmac-SIG] MPW In-Reply-To: Message by Rod Morehead , Fri, 23 Oct 1998 13:25:13 -0500 (CDT) , <13872.51721.642507.697448@ghostwheel> Message-ID: Recently, Rod Morehead said: > Bill Bedford writes: > > Some time ago various people were talking of trying to complie python unde > r > > MPW. Has anyone done it yet? and would they like to share their experience > s? > > I think one of the biggest problems right now is the lack of a GUSI to > go with any recent MPW release. If this is the only showstopper it can possibly be solved: GUSI still includes the projects to build an MPW library. I'm not 100% sure though what this means, it could either mean (a) a CW-formatted library for use in CW-projects to build MPW tools, or (b) an MPW-formatted library for use in MPW. Does anyone know for sure whether the library format is the same for MPW and CW? And, of course, it should also still be possible to build Python without GUSI. I haven't done it for a long time, but I can't imagine that there are big problems (probably just a few oversights, things that should have been inside #ifdef USE_GUSI). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From dozier@bellatlantic.net Mon Oct 26 05:21:04 1998 From: dozier@bellatlantic.net (Bill Dozier) Date: Mon, 26 Oct 1998 00:21:04 -0500 Subject: [Pythonmac-SIG] GUI suggestion? Message-ID: Hi all, I'm still working on my MIDI-sysex librarian/editor (if anyone has a contact at Roland-Japan and can get a sysex map for the VG-8, I'd be ever so grateful!) and will soon be ready to start on a user interface. What I would love to do is to allow the user to drag & drop patches between windows to build collections of patches and within a window to reorder them. I guess that I would be displaying columnar lists of patch names & numbers. For reference, I have not done any GUI stuff outside of Tk on UNIX and OpenStep. Does the Framework module have enough in it for this kind of thing, or do I have to build the GUI in PowerPlant and make my own interface for it to Python? I am not happy with the appearance or stability of the Mac Tk port, so I'd rather go native. I don't think Tk supports drag & drop, anyway. Any suggestions, pointers to examples, etc. would be appreciated. Thanks, Bill Bill Dozier Mortgage Physicist From Heinz-Guenter.Hermanns@physik.rwth-aachen.de Tue Oct 27 14:12:22 1998 From: Heinz-Guenter.Hermanns@physik.rwth-aachen.de (Heinz-Guenter Hermanns) Date: Tue, 27 Oct 1998 15:12:22 +0100 Subject: [Pythonmac-SIG] NumPy again References: <199810161600.MAA10860@python.org> Message-ID: <3635D4C6.FA9A7CFE@physik.rwth-aachen.de> Hello, a short time ago there was a discussion about further supporting NumPy for the Mac. I am not an experienced programmer but i have CW2 and would like to help supporting it. Could anyone give a summery of the state of the art? Does anyone allready have new versions of NumPy? Please do not throw your CW projects away. Please send them to me. Thanks HG -- ---------------------------------------------------------- Heinz-Guenter Hermanns RWTH Aachen Institut fuer Theoretische Physik A Huyskensweg D-52056 Aachen Tel: +49-241-80 70 20, Fax: +49-241-8888 188, Telex: 08 32 704 Email: Heinz-Guenter.Hermanns@physik.rwth-aachen.de ---------------------------------------------------------- From just@letterror.com Tue Oct 27 14:37:39 1998 From: just@letterror.com (Just van Rossum) Date: Tue, 27 Oct 1998 15:37:39 +0100 Subject: [Pythonmac-SIG] NumPy again In-Reply-To: <3635D4C6.FA9A7CFE@physik.rwth-aachen.de> References: <199810161600.MAA10860@python.org> Message-ID: At 3:12 PM +0100 10/27/98, Heinz-Guenter Hermanns wrote: >Hello, > >a short time ago there was a discussion about further supporting NumPy >for the Mac. > >I am not an experienced programmer but i have CW2 and would like to help >supporting it. > >Could anyone give a summery of the state of the art? > >Does anyone allready have new versions of NumPy? > >Please do not throw your CW projects away. >Please send them to me. I've got a working NumPy 1.6 for Python 1.5.1. I'll send it to you in a separete email, including CW3 project. Not sure it that's compatible with CW2, though. Just From joanca@seker.es Tue Oct 27 15:45:50 1998 From: joanca@seker.es (JoanCarles p Casas=?ISO-8859-1?Q?=edn?=) Date: Tue, 27 Oct 98 17:45:50 +0200 Subject: [Pythonmac-SIG] maclib doc Message-ID: <0570b21.199810271745.0012BB4C@seker.es> Hi you all, I'm looking for maclib documentation (.html format) but I can't find where to download it from. I've got the pdf version but I prefer the html (better to browse) Is it somewhere?? thanks, JoanCarles...Typerware® From sdm7g@virginia.edu Tue Oct 27 16:56:19 1998 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Tue, 27 Oct 1998 11:56:19 -0500 (EST) Subject: [Pythonmac-SIG] mac.chdir ? Message-ID: I would love it if we could find a place in the standard library for a function that does the following one liner: os.chdir( macfs.GetDirectory()[0].as_pathname() ) Only problem: I don't know where it should go. macfs seems the logical place, however, it's a builtin, not a .py file module. Alternatively: maybe a better way of linking the "current directory" returned by os.getcwd() and used by other Python file functions with the "magic" placeholder use by the Mac standard file dialogs. ( If there's any interest in the latter solution, I'll look up what we changed in XlispStat to make it track better. However, that only works if the Mac Control Panel is set to "Take me to folder set by the application" ) ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "I'm not as big a fool as I used to be, I'm a smaller fool." - Jack Kerouac Some of the Dharma From just@letterror.com Tue Oct 27 17:19:36 1998 From: just@letterror.com (Just van Rossum) Date: Tue, 27 Oct 1998 18:19:36 +0100 Subject: [Pythonmac-SIG] mac.chdir ? In-Reply-To: Message-ID: At 11:56 AM -0500 10/27/98, Steven D. Majewski wrote: >I would love it if we could find a place in the standard library >for a function that does the following one liner: > >os.chdir( macfs.GetDirectory()[0].as_pathname() ) > >Only problem: I don't know where it should go. macfs seems the >logical place, however, it's a builtin, not a .py file module. > > >Alternatively: maybe a better way of linking the "current directory" >returned by os.getcwd() and used by other Python file functions with >the "magic" placeholder use by the Mac standard file dialogs. > >( If there's any interest in the latter solution, I'll look up > what we changed in XlispStat to make it track better. However, > that only works if the Mac Control Panel is set to "Take me to > folder set by the application" ) There is function in macfs that was planned to do what you want, it's called SetFolder(). Bad thing is: it doesn't work anymore. It used to be that you had to fiddle with LMSetCurDirStore and friends but now Apple reccommends to do it with a filter function in CustomGetFile(), which is kind of a pain from a Python perspective. I don't know what we should do, but I'd love to see that functionality as well. Just From spillar@uwyo.edu Tue Oct 27 18:25:37 1998 From: spillar@uwyo.edu (Earl Spillar) Date: Tue, 27 Oct 1998 11:25:37 -0700 Subject: [Pythonmac-SIG] Re: NumPy Again! Message-ID: <9810271825.AA00315@galaxies.uwyo.edu> Just and Heintz, I too am very interested in getting NumPy1.6 & Python1.51 for Mac! Could some kind soal send me a copy? Perhaps I can help too: I have CW3 on my mac. I'm not a real Mac hacker yet; more of a NeXTStep person. But if you send me appropriate project I might be able to compile. Earl Spillar spillar@uwyo.edu From sdm7g@virginia.edu Tue Oct 27 18:46:34 1998 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Tue, 27 Oct 1998 13:46:34 -0500 (EST) Subject: [Pythonmac-SIG] mac.chdir ? In-Reply-To: Message-ID: On Tue, 27 Oct 1998, Just van Rossum wrote: > There is function in macfs that was planned to do what you want, it's > called SetFolder(). Bad thing is: it doesn't work anymore. It used to be > that you > had to fiddle with LMSetCurDirStore and friends but now Apple reccommends > to do it with a filter function in CustomGetFile(), which is kind of a pain > from a Python perspective. I don't know what we should do, but I'd love to > see that functionality as well. SetFolder() seems to work for me, however what it does isn't what my code fragment does. SetFolder() changes (I assume) LMSetCurDirStore so that you can set the starting folder for all of the macfs standard file dialogs. If you don't give it an arg, the default is to set it the same as getcwd(). All I wanted was a quickie to set the current directory interactively: os.chdir( macfs.GetDirectory()[0].as_pathname() ) and, since I use this quite frequently, I though it might be a good addition to the standard library. But this topic always tends to get confusing because the problem is that there's TWO "current-directories" -- the POSIX/STDIO getcwd() current-working-directory, and the Mac standard file dialog Current Folder and they don't track each other of have any connection. If there's a function missing from the set, it's a way to get the current Standard File Current Folder. I don't see that anywhere -- am I missing something ? You can, however, set that starting folder to the POSIX cwd so that they are initially in sync. If you need to keep them in sync after that, it looks like it would be a bit of a pain without that missing function. However, my memory was that that location gets overwritten -- it's a "global" that may be different for each app -- an so it's only valid at certain times. What Mac XlispStat does is add an extra optional boolean arg to the standard file dialogs to indicate whether the POSIX cwd should be updated from the directory of the selected file. You could obviously wrap the macfs file dialogs in code that: [1] does a SetFolder to set it to POSIX cwd [2] does the dialog [3] if a file spec is returned, chdir() to the directory of that file. The "bit of a pain" is that you have to make sure that you wrap them all - StandardGetFile, PromptGetFile, StandardPutFile and GetDirectory -- (did I get them all?) -- or they'll get out of sync. BTW: For the original question, how about making os.getcwd() into a wrapper around the existing getcwd(), with a no-arg-optional behaviour that calls GetDirectory ? ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "I'm not as big a fool as I used to be, I'm a smaller fool." - Jack Kerouac Some of the Dharma From Jack.Jansen@cwi.nl Tue Oct 27 19:37:34 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 27 Oct 1998 20:37:34 +0100 Subject: [Pythonmac-SIG] mac.chdir ? In-Reply-To: Message by "Steven D. Majewski" , Tue, 27 Oct 1998 13:46:34 -0500 (EST) , Message-ID: Recently, "Steven D. Majewski" said: > SetFolder() seems to work for me, however what it does isn't what my > code fragment does. Yes, but as was mentioned before it only works if you have the right settings in the "general controls" control panel:-( I'm working on a different hook for setting the folder for the StandardFile calls, probably an extra optional argument that signifies the folder where you want to go. It's not simple, though, because it'll have to use the event hook, and that's already used for other things. > All I wanted was a quickie to set the current directory interactively: > > os.chdir( macfs.GetDirectory()[0].as_pathname() ) A good place to put this would be the interactive startup file, or, if you use the IDE, the scripts folder. > But this topic always tends to get confusing because the problem is > that there's TWO "current-directories" -- the POSIX/STDIO getcwd() > current-working-directory, and the Mac standard file dialog Current > Folder and they don't track each other of have any connection. This is because the MacOS doesn't really have a working directory concept. I keep noticing that various extensions also muck with Python's idea of the working directory: Click there it is! is one of them, and the valuefax receiver is another. There's unfortunately little to do about this, short of completely ignoring MacOS's working directory and keeping the working directory ourselves:-( > If there's a function missing from the set, it's a way to get the > current Standard File Current Folder. I don't see that anywhere -- > am I missing something ? It's the return value of macfs.SetFolder(). > BTW: For the original question, how about making os.getcwd() into > a wrapper around the existing getcwd(), with a no-arg-optional > behaviour that calls GetDirectory ? What exactly do you solve here? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From just@letterror.com Tue Oct 27 19:59:59 1998 From: just@letterror.com (Just van Rossum) Date: Tue, 27 Oct 1998 20:59:59 +0100 Subject: [Pythonmac-SIG] ANN: NumPy 1.6 distributions for Mac Message-ID: I've put a binary distribution of NumPy 1.6 for MacPython 1.5.1 at: and CodeWarrior stuff for people who want to build it themselves here: Note that the latter is just a folder containing a CW project and some .exp files, it merely supplements the official LLNL sources. Oh, it is PPC-only, sorry. Just From sdm7g@virginia.edu Tue Oct 27 20:39:50 1998 From: sdm7g@virginia.edu (Steven D. Majewski) Date: Tue, 27 Oct 1998 15:39:50 -0500 (EST) Subject: [Pythonmac-SIG] mac.chdir ? In-Reply-To: Message-ID: On Tue, 27 Oct 1998, Jack Jansen wrote: [...] > A good place to put this would be the interactive startup file, or, if > you use the IDE, the scripts folder. [...] > > BTW: For the original question, how about making os.getcwd() into > > a wrapper around the existing getcwd(), with a no-arg-optional > > behaviour that calls GetDirectory ? > > What exactly do you solve here? Just a convenience. On the Mac, I can't just cd to the directory where my current data files are and type "python" and expect it to startup ready to go, like I do on unix. ( And for some reason, Mac folder names always seem to have spaces, funny option characters or maybe just that the relative filename rules are slightly more awkward than unix -- how far up is "::::" ? -- little quirks that seem to make it take me a couple of trys to get os.chdir() with a literal correct! ) I've put that definition in *my* startup file, but I was just wondering if this was anoying enough to everyone else to merit adding to the standard libraries somewhere. If the answer is "NO", then "Nevermind!" ( *I* find it highly anoying, but I haven't been using the IDE -- maybe THAT's my problem! ;-) ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "I'm not as big a fool as I used to be, I'm a smaller fool." - Jack Kerouac Some of the Dharma From werdna@gate.net Sat Oct 31 04:55:53 1998 From: werdna@gate.net (Andrew C. Greenberg) Date: Fri, 30 Oct 1998 23:55:53 -0500 Subject: [Pythonmac-SIG] pythonmac & GUI In-Reply-To: Message-ID: Bob Savage writes: >I have been slowly learning Python, but have yet to do anything with a GUI. >I tried Tkinter a few times, but it doesn't seem to work reliably for me. I >tried running the 'Hello GUI world' code from the Lutz tome, and I ended up >not being able to quit from the Python IDE (the menubar changes to reflect >the mini app, but 'quit' does not work, so all I can do is force quit??) >The same thing happened on two different computers, BTW. Lately, I've been looking for a decent vehicle for facilitating GUI "dabbling" on the Macintosh, as I have found myself hacking together a bunch of special purpose "one to throw away" applications for my family of late. As is my wont, I return to python as a wonderful vehicle for that sort of thing, lamenting the difficulty in producing a passable GUI. Each time I do this, I go back to, but usually abandon Python for more "traditional" development environments, never quite satisfied with the GUI's I've been able to generate with relatively minimal effort. Tkinter seemed too fragile, and the framework seemed to require too much work for the bang compared, say, to the more powerful Codewarrier frameworks. JPython held my interest for quite a while this time (what a really wonderful and elegant hack!), but then, awt being what it is made me long for the virtues of MPW. This time I stuck with Tkinter a bit longer than usual, and seem to have managed to make it "stick.". Although I found the menu mechanisms EXTREMELY fragile at first, crashing and burning and forcing hard-quits WAY too often, I eventually found a protocol that worked reliably and wrapped defensively from that fragility in a stable application framework. The reward seemed worthwhile: I now am able to put together straightforward simple applications without thinking too hard about Tkinter's fragility, enjoying the virtues of Python without the fears of runnning into the next breakpoint. If there is interest, I will be pleased to post that quasi-"solution" once I am a little less embarassed by the general state of the code. Digging into all the Tcl/Tk documentation yielded one neat reward that might be of interest to some in the MacPython Sig: I found a reference in the Macintosh Tk 8.0 FAQ to an "undocumented" facility to generate windows with window styles other than the standard zoomDocProc in the Macintosh version of Wish. It turns out that a call to Tk command undocumented1 style window styledescriptor before a window is first displayed will yield a window using an alternative document style. This trick is best illustrated with the following script, which produces a listbox you can click to view the next style. I haven't been able to change the style for a window that has already been displayed, however, and remain curious if that is possible. Accordingly, the present script has to spawn a new window, self-destructing the present window to achieve the desired effect. Moreover, I am unable to change the style of the root window. Of course the virtue of Tkinter is generally its machine independence. Still, its nice to make Mac programs that look and behave more like Mac programs, particularly when I am just prototyping GUI's to "make one to throw away." ----- import Tkinter,sys,string styles = [ 'documentProc', 'dBoxProc', 'plainDBox', 'altDBoxProc', 'movableDBoxProc', 'zoomDocProc', 'rDocProc', 'floatProc', 'floatZoomProc', 'floatSideProc', 'floatSideZoomProc' ] class FunnyStyleWindow(Tkinter.Toplevel): def __init__(self,master=None,style='documentProc'): self.master = master Tkinter.Toplevel.__init__(self,master) self.withdraw() self.mac_style(style) self.geometry('+100+100') self.title(style) self.resizable(0,0) self.lb = Tkinter.Listbox(self) for i in styles: self.lb.insert(Tkinter.END,i) self.lb.bind('',self.handleclick) self.lb.pack() self.deiconify() def mac_style(self,string): return self.tk.call('unsupported1','style', self._w, string) def handleclick(self,*args): e = args[0] lb = e.widget idx = lb.index('@'+repr(e.x)+','+repr(e.y)) newstyle = lb.get(idx) FunnyStyleWindow(self.master,newstyle) self.destroy() root = Tkinter.Tk() FunnyStyleWindow() root.mainloop() From wtbridgman@radix.net Sat Oct 31 12:00:04 1998 From: wtbridgman@radix.net (W.T. Bridgman) Date: Sat, 31 Oct 1998 07:00:04 -0500 Subject: [Pythonmac-SIG] Plotting Widget problems Message-ID: A few months ago, Konrad Hinsen posted a python plotting widget written using the Tk interface at http://starship.skyport.net/crew/hinsen/TkPlotCanvas.py I've tried using this in MacPython but it doesn't seem to run. It seems to just compile and do nothing. Has anyone had a similar experience and/or figured out what is missing? Thanks, Tom