From greg.ewing at canterbury.ac.nz Tue Dec 1 00:44:05 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 01 Dec 2009 12:44:05 +1300 Subject: [Pygui] signals and slots In-Reply-To: <200911301414.02302.list@qtrac.plus.com> References: <4B130BEF.6040604@canterbury.ac.nz> <200911301414.02302.list@qtrac.plus.com> Message-ID: <4B1458C5.7040901@canterbury.ac.nz> Mark Summerfield wrote: > Signals and slots are used to combine widgets to get particular > behaviours, e.g., to only enable an OK button if various fields are > filled in, or to repsond to a button click, that kind of thing. Qt's > event handling mechanism is used for creating custom widgets. Yes, I know it's not quite the same thing, but it's an example of the same kind of plug-handler-into-slot programming style. Sometimes it's okay, other times it seems less concise than it could be. PyGUI's action properties actually let you treat it either way -- you can either plug in a handler or have it send an event message. > I know that it is nice creating things from scratch Actually, Qt is the one that's inventing things from scratch. They the advantage that they're implementing everything themselves, so they have total control over how it all works. PyGUI has to work with whatever the platform provides, and sometimes there are severe limitations on the hooks available for doing this kind of thing. A full-blown Qt-like signal-slot mechanism would be a nice thing to have, but it's not easy to build one on top of a system that wasn't designed for it. > PyQt represents > a lot of prior art that has proved very durable and popular so I think > you'd at least find it interesting to try it out I have used Qt, but it was a long time ago, and in C++ :-(. I'll take a look some time and see what it's like these days. Need to finish wrestling with printing first, though... -- Greg From greg.ewing at canterbury.ac.nz Tue Dec 1 01:00:50 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 01 Dec 2009 13:00:50 +1300 Subject: [Pygui] signals and slots In-Reply-To: References: <4B130BEF.6040604@canterbury.ac.nz> <200911301414.02302.list@qtrac.plus.com> Message-ID: <4B145CB2.5090600@canterbury.ac.nz> inhahe wrote: > The reason I like signals and slots so much is that slots is that I > don't need always need to subclass - I can often create widgets and > have things respond to them just by making the object in one line and > then connecting it the next. I find I hardly ever need to subclass widgets in PyGUI either, at least not controls. Usually I *do* create a subclass of Window or Dialog to act as a container for my controls. I tend to do this even when it's not strictly necessary, as a convenient way of organising the code. Having done that, it's very natural to give it a method that updates the state of the controls based on the prevailing conditions, and trigger it with action properties. -- Greg From list at qtrac.plus.com Tue Dec 1 09:48:39 2009 From: list at qtrac.plus.com (Mark Summerfield) Date: Tue, 1 Dec 2009 08:48:39 +0000 Subject: [Pygui] signals and slots In-Reply-To: <4B1458C5.7040901@canterbury.ac.nz> References: <200911301414.02302.list@qtrac.plus.com> <4B1458C5.7040901@canterbury.ac.nz> Message-ID: <200912010848.39139.list@qtrac.plus.com> On 2009-11-30, Greg Ewing wrote: > Mark Summerfield wrote: > > Signals and slots are used to combine widgets to get particular > > behaviours, e.g., to only enable an OK button if various fields are > > filled in, or to repsond to a button click, that kind of thing. Qt's > > event handling mechanism is used for creating custom widgets. > > Yes, I know it's not quite the same thing, but it's > an example of the same kind of plug-handler-into-slot > programming style. Sometimes it's okay, other times it > seems less concise than it could be. PyGUI's action > properties actually let you treat it either way -- > you can either plug in a handler or have it send an > event message. > > > I know that it is nice creating things from scratch > > Actually, Qt is the one that's inventing things from > scratch. They the advantage that they're implementing > everything themselves, so they have total control over > how it all works. > > PyGUI has to work with whatever the platform provides, > and sometimes there are severe limitations on the hooks > available for doing this kind of thing. If you go that route you may end up doing things the wxWidgets/wxPython way. For single-platform development that's no problem, but for those who want to develop cross-platform GUI applications it is a real pain (in wx) that some of the widgets are platform-specific, so you can't guarantee uniform functionality. I think in the end they had to develop generic widgets (which as you know, is the route Qt took). Using the underlying widgets will give you a fast track to having something that works---but to avoid frustration later on I hope you'll (1) provide a mechanism for creating custom widgets (with full control over both appearance and behaviour), and (2) you'll provide a fully cross-platform API so that people don't get caught out just because they've changed platform. > A full-blown Qt-like signal-slot mechanism would be a > nice thing to have, but it's not easy to build one on > top of a system that wasn't designed for it. > > > PyQt represents > > a lot of prior art that has proved very durable and popular so I think > > you'd at least find it interesting to try it out > > I have used Qt, but it was a long time ago, and in > C++ :-(. I'll take a look some time and see what it's > like these days. Need to finish wrestling with printing > first, though... That was probably Qt 3 or earlier---Qt 4 is much more mature, consistent, and wide-ranging in its functionality---and is LGPL of course. I'm not really sure why (apart from the fun of it:-) you want to build another Python GUI --- after all, if you want to ground break you could help out the PySide guys. They're starting with PyQt (so they get massive functionality out of the box), but they are not tying themselves down to the PyQt API... -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Programming in Python 3 (Second Edition)" - ISBN 0321680561 From list at qtrac.plus.com Tue Dec 1 09:52:12 2009 From: list at qtrac.plus.com (Mark Summerfield) Date: Tue, 1 Dec 2009 08:52:12 +0000 Subject: [Pygui] signals and slots In-Reply-To: <4B145CB2.5090600@canterbury.ac.nz> References: <4B145CB2.5090600@canterbury.ac.nz> Message-ID: <200912010852.12864.list@qtrac.plus.com> On 2009-12-01, Greg Ewing wrote: > inhahe wrote: > > The reason I like signals and slots so much is that slots is that I > > don't need always need to subclass - I can often create widgets and > > have things respond to them just by making the object in one line and > > then connecting it the next. > > I find I hardly ever need to subclass widgets in PyGUI > either, at least not controls. > > Usually I *do* create a subclass of Window or Dialog to > act as a container for my controls. I tend to do this > even when it's not strictly necessary, as a convenient > way of organising the code. > > Having done that, it's very natural to give it a method > that updates the state of the controls based on the > prevailing conditions, and trigger it with action > properties. There is another way of maintaining state: use a state machine. Qt 4.6 facilitates this (although I think only a few examples make use of it yet). Nonetheless, I think it is interesting and given that it is property-based might be an approach worth considering for a really Pythonic GUI API: http://doc.trolltech.com/4.6-snapshot/statemachine-api.html -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Rapid GUI Programming with Python and Qt" - ISBN 0132354187 From greg.ewing at canterbury.ac.nz Wed Dec 2 00:57:14 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 02 Dec 2009 12:57:14 +1300 Subject: [Pygui] signals and slots In-Reply-To: <200912010848.39139.list@qtrac.plus.com> References: <200911301414.02302.list@qtrac.plus.com> <4B1458C5.7040901@canterbury.ac.nz> <200912010848.39139.list@qtrac.plus.com> Message-ID: <4B15AD5A.1040505@canterbury.ac.nz> Mark Summerfield wrote: > it is a real pain > (in wx) that some of the widgets are platform-specific, so you can't > guarantee uniform functionality. I'm very mindful of that problem, and I'm trying hard to ensure that all of the features PyGUI promises work acceptably well on all platforms. If something is missing on a platform, and I can fill it in reasonably easily with Python code, then I'm doing that. If it would require too much effort, sometimes I just have to leave things out. > Using the > underlying widgets will give you a fast track to having something that > works You make it sound like a cheap shortcut, but it's much more than that. Using platform widgets means you get exact platform appearance and behaviour, without missing any subtleties -- and it *stays* that way even if the platform changes. Also it's much more efficient that recreating everything in Python would be. > I hope you'll (1) provide a > mechanism for creating custom widgets (with full control over both > appearance and behaviour) Already done. You can create completely custom widgets in pure Python. Just subclass View and do whatever you want with it. > I'm not really sure why (apart from the fun of it:-) you want to build > another Python GUI My reasons are listed on the project page, and they still stand. I want to be able to distribute apps that can be used without having to install any large third-party libraries. Think of it as a modern-day replacement for Tkinter, designed to fill the same niche. -- Greg From greg.ewing at canterbury.ac.nz Wed Dec 2 01:16:30 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 02 Dec 2009 13:16:30 +1300 Subject: [Pygui] signals and slots In-Reply-To: <200912010852.12864.list@qtrac.plus.com> References: <4B145CB2.5090600@canterbury.ac.nz> <200912010852.12864.list@qtrac.plus.com> Message-ID: <4B15B1DE.6040801@canterbury.ac.nz> Mark Summerfield wrote: > There is another way of maintaining state: use a state machine. > http://doc.trolltech.com/4.6-snapshot/statemachine-api.html Hmmm. At first sight it appears to be an extremely complicated solution to something that isn't much of a problem in the first place, at least not in Python. Seems to me a Pythonic approach to this would be just to write some code, or use dicts to model the state transitions. -- Greg From list at qtrac.plus.com Wed Dec 2 09:52:13 2009 From: list at qtrac.plus.com (Mark Summerfield) Date: Wed, 2 Dec 2009 08:52:13 +0000 Subject: [Pygui] signals and slots In-Reply-To: <4B15AD5A.1040505@canterbury.ac.nz> References: <200912010848.39139.list@qtrac.plus.com> <4B15AD5A.1040505@canterbury.ac.nz> Message-ID: <200912020852.13468.list@qtrac.plus.com> On 2009-12-01, Greg Ewing wrote: > Mark Summerfield wrote: > > it is a real pain > > (in wx) that some of the widgets are platform-specific, so you can't > > guarantee uniform functionality. > > I'm very mindful of that problem, and I'm trying hard to > ensure that all of the features PyGUI promises work acceptably > well on all platforms. > > If something is missing on a platform, and I can fill it in > reasonably easily with Python code, then I'm doing that. If > it would require too much effort, sometimes I just have to > leave things out. That sounds good. > > Using the > > underlying widgets will give you a fast track to having something that > > works > > You make it sound like a cheap shortcut, but it's much more > than that. Using platform widgets means you get exact platform > appearance and behaviour, without missing any subtleties -- > and it *stays* that way even if the platform changes. Yep. > Also it's > much more efficient that recreating everything in Python would > be. Not convinced by that at all---but then, you're the one writing it:-) > > I hope you'll (1) provide a > > mechanism for creating custom widgets (with full control over both > > appearance and behaviour) > > Already done. You can create completely custom widgets in > pure Python. Just subclass View and do whatever you want > with it. OK, that sounds really good! (I think I must have been looking at an older version, I can now see that you've done a _huge_ amount of work since then.) > > I'm not really sure why (apart from the fun of it:-) you want to build > > another Python GUI > > My reasons are listed on the project page, and they still stand. > I want to be able to distribute apps that can be used without > having to install any large third-party libraries. Think of it > as a modern-day replacement for Tkinter, designed to fill the > same niche. I really like your project aims---they are exactly what I was looking for years ago and the nearest I could find was PyQt which I think is superb, but isn't "native Python" in the way you're aiming for. A truly Pythonic replacement for Tkinter that's part of the standard library would be wonderful. -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Advanced Qt Programming" - ISBN 0321635906 From danchr at gmail.com Fri Dec 11 12:24:31 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Fri, 11 Dec 2009 12:24:31 +0100 Subject: [Pygui] Native wrappers? Message-ID: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> Hi, I must say I find the PyGUI project interesting. From my perspective, the lack of a good, cross-platform UI framework is the major thing missing from Python as-is. I especially find it appealing that one of the goals listed is: ?Get the library and its documentation included in the core Python distribution, so that truly cross-platform GUI applications may be written that will run on any Python installation, anywhere.? The current implementations, however, use third party wrappers for platform specific frameworks. Wouldn't this prevent PyGUI from being considered for inclusion? For what it's worth, my brief experience with PyObjC is that it's *very* slow to just import; about a second on a 2.26GHz Core 2 Duo. Using a simplified, custom wrapper ought to yield much better startup times, if nothing else. I've checked the source code, and it seems that the starting point for implementing a native Cocoa wrapper would be Applications and Events modules. Is this correct? I might toy around a bit with writing it :) For what it's worth, I've put a Mercurial repository with all released versions of PyGUI at Bitbucket: -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From greg.ewing at canterbury.ac.nz Fri Dec 11 22:48:57 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 12 Dec 2009 10:48:57 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> Message-ID: <4B22BE49.3060703@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > The current implementations, however, use third party wrappers for platform > specific frameworks. Wouldn't this prevent PyGUI from being considered for > inclusion? Well, that doesn't seem to have stopped Tkinter from being included, so I wouldn't say it's impossible, but I agree that it's not an ideal situation, and I'd like to get away from all third-party dependencies eventually. It would be nice if it could be done purely in python, using ctypes. For gtk and win32 this would be straightforward, since the interfaces are all plain C calls (although some work would be needed to rebuild the MFC framework functionality I'm currently relying on). I'm not sure what to do about Cocoa, though. It's not obvious how to access objective-C functionality through ctypes, if it's even possible at all. > For what it's worth, my brief experience with PyObjC is that it's > *very* slow to just import; Yes, I've noticed that too, and it's a nuisance. I think PyObjC is going to a lot of trouble to make things look nice to the Python programmer, and it has a cost. PyGUI doesn't need any of that -- it doesn't matter if the interface is ugly, since the user of PyGUI isn't going to see any of it. Another possibility of course is to write an extension module that exposes the needed parts of Cocoa. > I've checked the source code, and it seems that the starting point > for implementing a native Cocoa wrapper would be Applications and Events > modules. Is this correct? Yes, that's probably about right. Essentially you should just work your way numerically through the tests, implementing what you need to make each one work. You may need to stub some things out in the early stages, e.g. menus, since the core of the framework is fairly intertwined. > I might toy around a bit with writing it :) That would be interesting, and very useful if you succeed. Good luck! -- Greg From danchr at gmail.com Fri Dec 11 23:18:11 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Fri, 11 Dec 2009 23:18:11 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B22BE49.3060703@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> Message-ID: <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> On 11 Dec 2009, at 22:48, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: > >> The current implementations, however, use third party wrappers for platform >> specific frameworks. Wouldn't this prevent PyGUI from being considered for >> inclusion? > > Well, that doesn't seem to have stopped Tkinter from being included, > so I wouldn't say it's impossible, but I agree that it's not an > ideal situation, and I'd like to get away from all third-party > dependencies eventually. Isn't the dependancy of Tkinter on a non-Python library? I can image that Python depending on Python libraries would create all sorts of nasty bootstrapping issues :) > It would be nice if it could be done purely in python, using ctypes. > For gtk and win32 this would be straightforward, since the interfaces > are all plain C calls (although some work would be needed to rebuild > the MFC framework functionality I'm currently relying on). > > I'm not sure what to do about Cocoa, though. It's not obvious how > to access objective-C functionality through ctypes, if it's even > possible at all. Technically, it *is* possible, as all Objective-C method calls are implemented as function calls to objc_msgSend, objc_msgSendSuper and specialised versions of them for methods returning struct or floating point values. (This is probably why Apple claims that Objective-C calls are ?only? twice as slow as C calls; every ObjC call *is* in fact two C calls.) However, I *really* don't think following that path is a good idea, as you'd have to re-implement parts of the Objective-C runtime, and which function calls to use even depend on architecture. (For example, ?objc_msgSend_fpret? isn't used on PowerPC.) Or to put it another way; accessing Objective-C using ctypes is possible in theory, but not in practice :) >> For what it's worth, my brief experience with PyObjC is that it's > > *very* slow to just import; > > Yes, I've noticed that too, and it's a nuisance. I think PyObjC is > going to a lot of trouble to make things look nice to the Python > programmer, and it has a cost. PyGUI doesn't need any of that -- it > doesn't matter if the interface is ugly, since the user of PyGUI > isn't going to see any of it. > > Another possibility of course is to write an extension module that > exposes the needed parts of Cocoa. I think implementing all (or most) of the wrapper in Objective-C is the past of least resistance. So far, I've begun implementing the Events module as an Objective-C extension; although I haven't tested it yet, it seems doable to me. Eventually, it might be feasible to create some utility functions/classes to ease the implementation of wrappers. >> I've checked the source code, and it seems that the starting point > > for implementing a native Cocoa wrapper would be Applications and Events > > modules. Is this correct? > > Yes, that's probably about right. Essentially you should just work > your way numerically through the tests, implementing what you need > to make each one work. You may need to stub some things out in the > early stages, e.g. menus, since the core of the framework is > fairly intertwined. Cool! One thing, though; Apple's Foundation and CoreFoundation libraries use 16-bit characters for their string implementations. Would it be valid to only support UCS-2 builds, or should both kinds of build be supported? If supported, UCS-4 builds would incur a performance penalty: strings would have to be translated when passed between Python & Objective-C. For UCS-2 builds, however, NSStrings can be created from unicode objects with neither copying nor converting them. (I once wrote a bit of code doing this, for a dummy Objective-C loader. The loader itself never got very far; I stalled at decoding Objective-C type encodings. But the simple string converter, I did write?) >> I might toy around a bit with writing it :) > > That would be interesting, and very useful if you succeed. > Good luck! Thanks :) -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From greg.ewing at canterbury.ac.nz Sat Dec 12 03:53:10 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 12 Dec 2009 15:53:10 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> Message-ID: <4B230596.80907@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > Isn't the dependancy of Tkinter on a non-Python library? > I can image that Python depending on Python libraries would create > all sorts of nasty bootstrapping issues :) Not sure what you mean by that. My point is that Tkinter is in the stdlib despite requiring a library (tcl/tk) that isn't bundled with all versions of Python and isn't necessarily available on all systems. More recently there's sqlite. > Or to put it another way; accessing Objective-C using ctypes is possible > in theory, but not in practice :) Hmm. Maybe some of the chores of selecting the right functions to call could be taken care of by a wrapper layer? > I've begun implementing the Events module as an Objective-C extension; > although I haven't tested it yet, it seems doable to me. The Events module is probably one of the easier ones, since the Event class is pretty self-contained. Some other parts may be trickier -- there are some places where I've made use of the ability to subclass an Objective-C class in Python and override its methods. You may need to do that as an extension type wrapping an Objective-C subclass of the relevant NS class. If you're interested, I could look into extending Pyrex with some syntax for making Objective-C method calls. > Would it be valid to only > support UCS-2 builds, or should both kinds of build be supported? > > If supported, UCS-4 builds would incur a performance penalty: I think dropping UCS-4 capability for this reason at this stage would be premature optimisation. I can't really see passing strings being a performance bottleneck in most situations. -- Greg From danchr at gmail.com Sun Dec 13 14:55:12 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Sun, 13 Dec 2009 14:55:12 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B230596.80907@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> Message-ID: <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> On 12 Dec 2009, at 03:53, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: > >> Isn't the dependancy of Tkinter on a non-Python library? > > I can image that Python depending on Python libraries would create > > all sorts of nasty bootstrapping issues :) > > Not sure what you mean by that. My point is that Tkinter is in > the stdlib despite requiring a library (tcl/tk) that isn't bundled > with all versions of Python and isn't necessarily available on > all systems. More recently there's sqlite. What I was referring to is that Tkinter isn't a Python library and doesn't require Python to compile. PyObjC and the other wrappers, however, do. >> Or to put it another way; accessing Objective-C using ctypes is possible in theory, but not in practice :) > > Hmm. Maybe some of the chores of selecting the right functions > to call could be taken care of by a wrapper layer? It could; Objective-C is quite dynamic and reflective. There is the problem of *types*, though: All Objective-C method selectors contain an encoded type signature. It would be necessary to find a way to convert structures, strings, data and whathaveyou to/from the two implementations. However, such an implementation would likely also to require a rewrite of most of the current implementation. I don't see what the advantage to that would be? From my perspective, writing the wrapper directly in Objective-C doesn't seem that much harder :) >> I've begun implementing the Events module as an Objective-C extension; > > although I haven't tested it yet, it seems doable to me. > > The Events module is probably one of the easier ones, since the > Event class is pretty self-contained. Some other parts may be > trickier -- there are some places where I've made use of the > ability to subclass an Objective-C class in Python and override > its methods. You may need to do that as an extension type > wrapping an Objective-C subclass of the relevant NS class. ?_PyGui_NSApplication? is an example of this, right? > If you're interested, I could look into extending Pyrex with > some syntax for making Objective-C method calls. I'm not terribly familiar with Pyrex myself, but I'm sure other people would appreciate such support :) >> Would it be valid to only > > support UCS-2 builds, or should both kinds of build be supported? >> If supported, UCS-4 builds would incur a performance penalty: > > I think dropping UCS-4 capability for this reason at this stage > would be premature optimisation. I can't really see passing strings > being a performance bottleneck in most situations. Good point. Fortunately, I figured out how to create an NSString that would refer to the buffer of a PyUnicodeObject in a way that *should* work with both kinds of build. If you're interested, I put what I have so far here: -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From greg.ewing at canterbury.ac.nz Mon Dec 14 11:51:44 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 14 Dec 2009 23:51:44 +1300 Subject: [Pygui] Printing coordinate system problem Message-ID: <4B2618C0.1070209@canterbury.ac.nz> I'm wrestling with printing support for PyGUI on Windows. I'd like to set up the coordinate system during printing so that (0, 0) is at the corner of the paper, so that I can arrange for the margins to have predictable sizes. However, the device context I get from calling PrintDlg() seems to be set up so that the origin is at the corner of the printable area of the page, which is smaller by some amount that depends on the printer being used. If I could find out the limits of the printable area, I could correct for this, but there doesn't seem to be any straightforward way of getting this information. It doesn't seem to appear anywhere in any of the structs returned by PrintDlg(), and I can't find any call that might extract it from the device context. Am I missing something? Surely this an issue that most applications that print have to deal with. How do they do it? -- Greg From vernondcole at gmail.com Mon Dec 14 15:03:16 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 14 Dec 2009 07:03:16 -0700 Subject: [Pygui] Printing coordinate system problem In-Reply-To: <4B2618C0.1070209@canterbury.ac.nz> References: <4B2618C0.1070209@canterbury.ac.nz> Message-ID: In searching for documentation, remember a quirk in Microsoft vocabulary... a "printer" is software, not hardware. The device on the corner of your desk with the paper in it is not a "printer", it is a "printing device." -- Not being an expert on writing Windows printer code, nevertheless let me venture a guess that there may be no way to do what you want. My reasoning hinges on a bad experience I had in the past... Using Crystal Reports, a rather expensive commercial product which uses Windows very well, I designed a very fancy Purchase Order form, which I tested on three or four different Windows printers. When I installed the application, the purchase orders would not print out correctly on another printer -- the one connected to my boss's PC (of course). I had to re-design the report a few pixels narrower. -- Please somebody tell Greg that I'm wrong. -- Vernon On Mon, Dec 14, 2009 at 3:51 AM, Greg Ewing wrote: > I'm wrestling with printing support for PyGUI on Windows. > I'd like to set up the coordinate system during printing > so that (0, 0) is at the corner of the paper, so that I > can arrange for the margins to have predictable sizes. > > However, the device context I get from calling PrintDlg() > seems to be set up so that the origin is at the corner > of the printable area of the page, which is smaller by > some amount that depends on the printer being used. > > If I could find out the limits of the printable area, > I could correct for this, but there doesn't seem to be > any straightforward way of getting this information. > It doesn't seem to appear anywhere in any of the > structs returned by PrintDlg(), and I can't find any > call that might extract it from the device context. > > Am I missing something? Surely this an issue that most > applications that print have to deal with. How do they > do it? > > -- > Greg > _______________________________________________ > Pygui mailing list > Pygui at python.org > http://mail.python.org/mailman/listinfo/pygui > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theller at ctypes.org Mon Dec 14 21:42:09 2009 From: theller at ctypes.org (Thomas Heller) Date: Mon, 14 Dec 2009 21:42:09 +0100 Subject: [Pygui] Printing coordinate system problem In-Reply-To: <4B2618C0.1070209@canterbury.ac.nz> References: <4B2618C0.1070209@canterbury.ac.nz> Message-ID: Am 14.12.2009 11:51, schrieb Greg Ewing: > I'm wrestling with printing support for PyGUI on Windows. > I'd like to set up the coordinate system during printing > so that (0, 0) is at the corner of the paper, so that I > can arrange for the margins to have predictable sizes. > > However, the device context I get from calling PrintDlg() > seems to be set up so that the origin is at the corner > of the printable area of the page, which is smaller by > some amount that depends on the printer being used. > > If I could find out the limits of the printable area, > I could correct for this, but there doesn't seem to be > any straightforward way of getting this information. > It doesn't seem to appear anywhere in any of the > structs returned by PrintDlg(), and I can't find any > call that might extract it from the device context. > > Am I missing something? Surely this an issue that most > applications that print have to deal with. How do they > do it? > I would guess that GetDeviceCaps() returns the information that you need. -- Thanks, Thomas From greg.ewing at canterbury.ac.nz Mon Dec 14 23:40:39 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 15 Dec 2009 11:40:39 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> Message-ID: <4B26BEE7.5020703@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > Objective-C is quite dynamic and reflective. There is the problem of *types*, > though: All Objective-C method selectors contain an encoded type signature. I was envisaging something ctypes-like in that you would be responsible for telling it what the expected argument types are. But very low-level details like selecting different versions of a function based on architecture could be automated. There must surely be a middle ground somewhere between full-blown PyObjC and dealing directly with the raw ObjC runtime. > ?_PyGui_NSApplication? is an example of this, right? Yes, that's one of them. Another wrinkle is that in a few places I'm faking multiple inheritance in subclasses of NS types by using a metaclass that merges class dictionaries together. Although that might actually become simpler if the wrappers end up being normal Python types that support multiple inheritance directly. -- Greg From greg.ewing at canterbury.ac.nz Mon Dec 14 23:55:31 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 15 Dec 2009 11:55:31 +1300 Subject: [Pygui] Printing coordinate system problem In-Reply-To: References: <4B2618C0.1070209@canterbury.ac.nz> Message-ID: <4B26C263.6040506@canterbury.ac.nz> Vernon Cole wrote: > In searching for documentation, remember a quirk in Microsoft > vocabulary... a "printer" is software, not hardware. The device on the > corner of your desk with the paper in it is not a "printer", it is a > "printing device." Yes, I know. I'll be happy if I can somehow find out what the driver for whichever printer has been selected in the PrintDlg box thinks the printable area is for the selected paper size. If that doesn't match what the actual printer uses, that's not my problem. :-) Delving a bit further, it looks like I may be able to find out via GetPrinter() and GetForm()... I'll try an experiment shortly. > Using Crystal Reports, a rather expensive commercial product which uses > Windows very well, I designed a very fancy Purchase Order form, which I > tested on three or four different Windows printers. When I installed > the application, the purchase orders would not print out correctly on > another printer Configuring printer drivers on Windows can be a massively confusing and frustrating experience, especially when a network is involved. Chance are there was a setting somewhere in the maze of dialog boxes that would have made it work properly... or maybe not... -- Greg From greg.ewing at canterbury.ac.nz Tue Dec 15 12:15:50 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 16 Dec 2009 00:15:50 +1300 Subject: [Pygui] Solved - Printing coordinate system problem In-Reply-To: References: <4B2618C0.1070209@canterbury.ac.nz> Message-ID: <4B276FE6.5040907@canterbury.ac.nz> Thomas Heller wrote: > I would guess that GetDeviceCaps() returns the information that you need. Yep, this turns out to be right, although it's *very* difficult to find this out if you start looking in the area of the docs that talks about printing! My margins are spot-on now. I'm happy. Need sleep now. Thanks, everyone. -- Greg From danchr at gmail.com Tue Dec 15 12:52:54 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Tue, 15 Dec 2009 12:52:54 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B26BEE7.5020703@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> Message-ID: On 14 Dec 2009, at 23:40, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: >> Objective-C is quite dynamic and reflective. There is the problem of *types*, >> though: All Objective-C method selectors contain an encoded type signature. > > I was envisaging something ctypes-like in that you would be > responsible for telling it what the expected argument types are. > But very low-level details like selecting different versions of > a function based on architecture could be automated. > > There must surely be a middle ground somewhere between full-blown > PyObjC and dealing directly with the raw ObjC runtime. Good point. An option would be to write a proxy for a Python object/class as a new Objective-C root class implementing the NSObject protocol.[1] Whenever queried for a selector, it would somehow search the Python runtime for a matching method descriptor. There would still be a need for converting or bridging some of the fundamental types, though. I can think of these: * unicode ? NSString * tuple ? NSArray * list ? NSMutableArray * dict ? NSMutableDictionary * tuple? ? structs (e.g. NSPoint, NSRect?) Most of this would also be needed for a less general bridge, such as the one I'm hacking on. Of the various types, strings seem to be most used. The simple wrapper I wrote works, but it's quite far from ideal. Bridging dictionaries could be done using a slow, temporary hack that would employ ?plistlib? and ?[NSDictionary description]? to serialise in one API and de-serialise in the other. I'm not sure about the rest of the types, except that subclassing in Cocoa may not be an option. Some of the types are implemented as so-called class clusters which don't allow subclassing. It might be preferable to implement Python types wrapping concrete Objective-C instances instead. Concerning PyObjC, I suspect its slowness doesn't come from how it integrates with the language, but rather the fact that it instantiates all types eagerly, and does so in a fashion that corresponds almost exactly to how they are instantiated in Cocoa. This, combined with the huge headers Apple provide, results in the horrible launch times seen by it. For example, just loading the Cocoa framework does quite a lot of work up front: % python -v -c '' |& wc -l 97 % python -v -c 'import Cocoa' |& wc -l 411 % python -c 'import Cocoa; print(len(dir(Cocoa)))' 6047 I believe PyObjC implements its wrappers based on the BridgeSupport[2] descriptions in XML. Some of the data included in the XML files is also embedded in the framework binaries, whereas other data isn't. The embedded information includes class descriptions and method selector types, but not constants and utility functions such NSMakeRange(). I've tried to gather as much information as I could on the topic, but I've come to the realisation that actually *using* the knowledge is beyond my abilities :) I hope you find my descriptions useful! >> ?_PyGui_NSApplication? is an example of this, right? > > Yes, that's one of them. Did you try to implement the functionality provided by it using a delegate? Delegates seems to be the preferred in the Cocoa APIs, rather than subclassing. For what it's worth, I have the ?01-application? test running now, but without actually doing anything so far :) > Another wrinkle is that in a few places I'm faking multiple > inheritance in subclasses of NS types by using a metaclass > that merges class dictionaries together. Although that > might actually become simpler if the wrappers end up being > normal Python types that support multiple inheritance > directly. To be honest, I've never quite been comfortable with multiple inheritance :) I haven't used it much and regard it a bit like ?goto? ? structures which don't suite my way of thinking. [1] NSObject protocol reference [2] BridgeSupport -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From vernondcole at gmail.com Tue Dec 15 18:52:08 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Tue, 15 Dec 2009 10:52:08 -0700 Subject: [Pygui] [python-win32] Solved - Printing coordinate system problem In-Reply-To: <4B276FE6.5040907@canterbury.ac.nz> References: <4B2618C0.1070209@canterbury.ac.nz> <4B276FE6.5040907@canterbury.ac.nz> Message-ID: You're the Man, Thomas! You, too, Greg! Now I have to get my latest upgrade to adodbapi done so I can put some time into really using pygui. -- Vernon On Tue, Dec 15, 2009 at 4:15 AM, Greg Ewing wrote: > Thomas Heller wrote: > > I would guess that GetDeviceCaps() returns the information that you need. >> > > Yep, this turns out to be right, although it's *very* > difficult to find this out if you start looking in > the area of the docs that talks about printing! > > My margins are spot-on now. I'm happy. > > Need sleep now. > > Thanks, everyone. > > -- > Greg > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > http://mail.python.org/mailman/listinfo/python-win32 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Tue Dec 15 23:12:09 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 16 Dec 2009 11:12:09 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> Message-ID: <4B2809B9.5000403@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > Did you try to implement the functionality provided by it > using a delegate? A delegate could probably be used for some of it, but not all -- e.g. I'm overriding sendEvent: in the application and doing some processing on all the events that pass through. Also I'm overriding all the mouse and keyboard event handlers on most widgets so that PyGUI code can intercept events. > To be honest, I've never quite been comfortable with multiple > inheritance :) I haven't used it much and regard it a bit like ?goto? ? > structures which don't suite my way of thinking. The way I'm using it is just to share the implementations of a bunch of methods. E.g. all the event handling overrides are the same for most of the NSView objects that I want to use them on, but the NS objects already have their own idea of what class they are, so I can't make them singly-inherit from a common base class. So I have a PyGUI_NSEventHandler class containing just those methods, and mix it in with whatever class needs to use them. -- Greg From danchr at gmail.com Sat Dec 19 23:36:22 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Sat, 19 Dec 2009 23:36:22 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B2809B9.5000403@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> Message-ID: On 15 Dec 2009, at 23:12, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: > >> Did you try to implement the functionality provided by it using a delegate? > > A delegate could probably be used for some of it, but > not all -- e.g. I'm overriding sendEvent: in the application > and doing some processing on all the events that pass through. > Also I'm overriding all the mouse and keyboard event handlers > on most widgets so that PyGUI code can intercept events. Indeed, I realised later on that a delegate wouldn't suffice :) I believe I'm progressing nicely on the ?01-application? test. I just got basic menus working, but I'm seeing a weird issue; for some reason ?Open as?? and ?Save as?? create a menu item per character in their name. I've attached a screen shot of it below. Do you have an suggest as to might is cause this? As far as I can tell, those are the actual items passed to the Menus module? -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: shot.png Type: image/png Size: 9466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From greg.ewing at canterbury.ac.nz Sun Dec 20 04:04:15 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 20 Dec 2009 16:04:15 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> Message-ID: <4B2D942F.103@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > I'm seeing a weird issue; for some reason ?Open as?? and ?Save as?? > create a menu item per character in their name. Sounds like it thinks they're menu item groups instead of single items. Are these perhaps unicode strings? In Generic/GMenus.py, Menu._make_item(), there's the following piece of code: if isinstance(text, str): return SingleMenuItem(text, cmd, substitutions) else: return MenuItemGroup(text, cmd) This could get confused if it's given a unicode string instead of a plain str. It should probably be amended to take unicode into account. -- Greg From greg.ewing at canterbury.ac.nz Mon Dec 21 00:55:59 2009 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 21 Dec 2009 12:55:59 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: <397377D4-FCD6-49D1-BCEE-F1FD0229F7D5@gmail.com> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> <397377D4-FCD6-49D1-BCEE-F1FD0229F7D5@gmail.com> Message-ID: <4B2EB98F.6060509@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > The relevant snippet of code in -[PyApplication sendEvent:] looks like this: > > r = PyObject_CallMethod(*self*.app, "handle", "OO", kind, pyevent); > > *if* (r == *NULL*) { > PyObject_CallMethod(*self*.app, "report_error", ""); > } > > I'm not terribly familiar with how exceptions work with the Python API, > but shouldn't that suffice? No. Catching and handling exceptions in C code is rather tricky, especially if you want Python code to subsequently access the exception using sys.exc_info(), which is what report_error() is trying to do. I don't have time right now to explain in detail what needs to be done. In the meantime I suggest you just call PyErr_WriteUnraisable if you get an exception in a context where you can't propagate it to the caller. (BTW, this would be another good reason to use Pyrex -- it takes care of all the gory details of exception handling for you.) -- Greg From danchr at gmail.com Sun Dec 20 17:41:39 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Sun, 20 Dec 2009 17:41:39 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B2D942F.103@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> Message-ID: <397377D4-FCD6-49D1-BCEE-F1FD0229F7D5@gmail.com> On 20 Dec 2009, at 04:04, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: > >> I'm seeing a weird issue; for some reason ?Open as?? and ?Save as?? > > create a menu item per character in their name. > > Sounds like it thinks they're menu item groups instead of > single items. > > Are these perhaps unicode strings? In Generic/GMenus.py, > Menu._make_item(), there's the following piece of code: > > if isinstance(text, str): > return SingleMenuItem(text, cmd, substitutions) > else: > return MenuItemGroup(text, cmd) > > This could get confused if it's given a unicode string > instead of a plain str. It should probably be amended to > take unicode into account. Indeed; changing the check to basestring fixed it :) (It was caused by me making ?Save as??, etc., use Unicode strings for the ellipsis.) I have another issue where you may have an idea what I'm doing wrong? > Traceback (most recent call last): > File "/opt/python/lib/python/GUI/Generic/GApplications.py", line 379, in report_error > raise > TypeError: exceptions must be classes or instances, not NoneType The relevant snippet of code in -[PyApplication sendEvent:] looks like this: r = PyObject_CallMethod(self.app, "handle", "OO", kind, pyevent); if (r == NULL) { PyObject_CallMethod(self.app, "report_error", ""); } I'm not terribly familiar with how exceptions work with the Python API, but shouldn't that suffice? (The ?app? property accessor imports the Applications module and calls the ?application()? accessor in it to obtain the PyGUI application instance.) (I sent this email as rich text because of the code paste; I hope you don't mind!) -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dialog.png Type: image/png Size: 24920 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From vernondcole at gmail.com Mon Dec 21 02:45:32 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Sun, 20 Dec 2009 18:45:32 -0700 Subject: [Pygui] Native wrappers? In-Reply-To: <4B2D942F.103@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> Message-ID: Greg and everyone: These days I am trying to make all of my programs super-portable -- CPython2.x, IronPython and Python3 on Windows and Linux. 2/3 of these use ONLY unicode strings. One of my reasons for migrating to PyGUI is because there are no plans for wxPython to run on any platform other than 2.x. I am guessing that PyGUI, being more simple, is going to be much easier to convert to the other compilers than its competition. What I am getting at is this advice from a very old programmer... try to make everything work correctly with unicode. It will make life much easier when conversion time comes around. When you do need byte strings, use a user-written function to produce them, not a built in. This is one that I have found useful: v v v v def str2bytes(sval): if sys.version_info < (3,0) and isinstance(sval, str): sval = sval.decode("latin1") return sval.encode("latin1") ^ ^ ^ ^ -- Vernon Cole On Sat, Dec 19, 2009 at 8:04 PM, Greg Ewing wrote: > Dan Villiom Podlaski Christiansen wrote: > > I'm seeing a weird issue; for some reason ?Open as?? and ?Save as?? >> > > create a menu item per character in their name. > > Sounds like it thinks they're menu item groups instead of > single items. > > Are these perhaps unicode strings? In Generic/GMenus.py, > Menu._make_item(), there's the following piece of code: > > if isinstance(text, str): > return SingleMenuItem(text, cmd, substitutions) > else: > return MenuItemGroup(text, cmd) > > This could get confused if it's given a unicode string > instead of a plain str. It should probably be amended to > take unicode into account. > > -- > Greg > _______________________________________________ > Pygui mailing list > Pygui at python.org > http://mail.python.org/mailman/listinfo/pygui > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danchr at gmail.com Mon Dec 21 10:53:13 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Mon, 21 Dec 2009 10:53:13 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B2EB98F.6060509@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> <397377D4-FCD6-49D1-BCEE-F1FD0229F7D5@gmail.com> <4B2EB98F.6060509@canterbury.ac.nz> Message-ID: <157EADFC-A2EC-4794-8C6D-D5894A620A81@gmail.com> On 21 Dec 2009, at 00:55, Greg Ewing wrote: > No. Catching and handling exceptions in C code is rather tricky, > especially if you want Python code to subsequently access the > exception using sys.exc_info(), which is what report_error() > is trying to do. > > I don't have time right now to explain in detail what needs to > be done. In the meantime I suggest you just call PyErr_WriteUnraisable > if you get an exception in a context where you can't propagate it to > the caller. > > (BTW, this would be another good reason to use Pyrex -- it takes > care of all the gory details of exception handling for you.) Looking at the Pyrex code, I figured out how to get it working :) Essentially, setting the exception fields in the thread state did the trick.[1] There may be more to it, but at least it works for now? [1] This is the relevant changeset: -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From danchr at gmail.com Mon Dec 21 11:05:29 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Mon, 21 Dec 2009 11:05:29 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> Message-ID: On 21 Dec 2009, at 02:45, Vernon Cole wrote: > Greg and everyone: > > These days I am trying to make all of my programs super-portable -- CPython2.x, IronPython and Python3 on Windows and Linux. 2/3 of these use ONLY unicode strings. One of my reasons for migrating to PyGUI is because there are no plans for wxPython to run on any platform other than 2.x. I am guessing that PyGUI, being more simple, is going to be much easier to convert to the other compilers than its competition. > > What I am getting at is this advice from a very old programmer... try to make everything work correctly with unicode. It will make life much easier when conversion time comes around. When you do need byte strings, use a user-written function to produce them, not a built in. This is one that I have found useful: > v v v v > def str2bytes(sval): > if sys.version_info < (3,0) and isinstance(sval, str): > sval = sval.decode("latin1") > return sval.encode("latin1") > ^ ^ ^ ^ For what it's worth, the NSString in Cocoa class uses UTF-16 internally, and offers a distinct NSData class for anything else. The current implementation of string conversion[1] only accepts ASCII strings in addition to Unicode. (Looking at the code just now, non-ASCII strings will probably cause a null dereference? I should fix that and make it leak less too.) It would simplify things quite a bit if only Unicode strings were accepted, but I can't say whether this would be accepted for backwards compatibility. I'm a rather young programmer myself, but I can say that my native Cocoa backend is quite far from being actually usable. Who knows, by the time it is, Python 3 could be in widespread usage ;) [1] The conversion source is here: -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From danchr at gmail.com Tue Dec 22 10:43:09 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Tue, 22 Dec 2009 10:43:09 +0100 Subject: [Pygui] Native wrappers? In-Reply-To: <4B2EB98F.6060509@canterbury.ac.nz> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> <397377D4-FCD6-49D1-BCEE-F1FD0229F7D5@gmail.com> <4B2EB98F.6060509@canterbury.ac.nz> Message-ID: <9B8A1B28-86C6-4109-9B04-1CADA526458A@gmail.com> Hi Greg, I managed to get the 01-application test running, and I'm now looking at the 02-window test. It uses multiple inheritance like you mentioned, and I can now see why you chose to use it. Without it, a lot of classes would have to contain a lot of duplicated, boilerplate code. As you also mentioned, Objective-C doesn't support multiple inheritance, but I have an idea how it might be mimicked. The documentation suggests using forwarding,[1] but that may not work with delegates and such, so I'd suggest another approach instead: The methods to be ?inherited? would be implemented as instance methods of a separate class, and this would be similar to the Components.PyGUI_NS_EventHandler Python class in this instance. This class would then provide a class method such as ?+copyMethodsTo:(Class)aclass? which would iterate over the instance methods of its class, and copy/add them to the given class. Rather than inheriting from this class, other classes ? such as the NSWindow subclass ? would call this method in their +initialize method. This should yield the same results as multiple inheritance, whilst remaining almost as simple and concise. Oh, I just remembered that I forgot to respond to this portion: On 21 Dec 2009, at 00:55, Greg Ewing wrote: > (BTW, this would be another good reason to use Pyrex -- it takes > care of all the gory details of exception handling for you.) I understand that Pyrex would probably ease the implementation. However, it seems to me that using it would run counter to the stated goals of the project, unless Pyrex itself was to be included into the Python core library. Or perhaps I misunderstand? [1] Section ?Forwarding and Multiple Inheritance? in the ?Objective-C Runtime Reference? -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: