🌐 Mailman 3 October 1998 - Pythonmac-SIG - python.org

MPW
by Bill Bedford Oct. 23, 1998

Oct. 23, 1998

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(a)mousa.demon.co.uk

2 1

Re: mac event loop
by Peter Sommerfeld Oct. 23, 1998

Oct. 23, 1998

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 ... <grin> > 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

1 0

Re: [Pythonmac-SIG] Re: mac event loop
by Jack Jansen Oct. 23, 1998

Oct. 23, 1998

> 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(a)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

1 0

Re: mac event loop
by Peter Sommerfeld Oct. 22, 1998

Oct. 22, 1998

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

1 0

Re: [Pythonmac-SIG] Re: mac event loop
by Jack Jansen Oct. 22, 1998

Oct. 22, 1998

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(a)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

1 0

Re: [Pythonmac-SIG] Re: mac event loop
by Jack Jansen Oct. 22, 1998

Oct. 22, 1998

> 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(a)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

1 0

Re: mac event loop
by Peter Sommerfeld Oct. 22, 1998

Oct. 22, 1998

> 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

1 0

Re: [Pythonmac-SIG] mac event loop
by Jack Jansen Oct. 22, 1998

Oct. 22, 1998

> > 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(a)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

2 1

mac event loop
by Peter Sommerfeld Oct. 21, 1998

Oct. 21, 1998

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 !

1 0

RandomArray problem...
by Gordon Worley Oct. 19, 1998

Oct. 19, 1998

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

2 1