pyobjc-dev Mailing List for PyObjC (Page 27)
Brought to you by:
ronaldoussoren
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(30) |
May
(18) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
|
Sep
(23) |
Oct
(180) |
Nov
(291) |
Dec
(95) |
2003 |
Jan
(338) |
Feb
(352) |
Mar
(97) |
Apr
(46) |
May
(226) |
Jun
(184) |
Jul
(145) |
Aug
(141) |
Sep
(69) |
Oct
(161) |
Nov
(96) |
Dec
(90) |
2004 |
Jan
(66) |
Feb
(87) |
Mar
(98) |
Apr
(132) |
May
(115) |
Jun
(68) |
Jul
(150) |
Aug
(92) |
Sep
(59) |
Oct
(52) |
Nov
(17) |
Dec
(75) |
2005 |
Jan
(84) |
Feb
(191) |
Mar
(133) |
Apr
(114) |
May
(158) |
Jun
(185) |
Jul
(62) |
Aug
(28) |
Sep
(36) |
Oct
(88) |
Nov
(65) |
Dec
(43) |
2006 |
Jan
(85) |
Feb
(62) |
Mar
(92) |
Apr
(75) |
May
(68) |
Jun
(101) |
Jul
(73) |
Aug
(37) |
Sep
(91) |
Oct
(65) |
Nov
(30) |
Dec
(39) |
2007 |
Jan
(24) |
Feb
(28) |
Mar
(10) |
Apr
(2) |
May
(18) |
Jun
(16) |
Jul
(21) |
Aug
(6) |
Sep
(30) |
Oct
(31) |
Nov
(153) |
Dec
(31) |
2008 |
Jan
(63) |
Feb
(70) |
Mar
(47) |
Apr
(24) |
May
(59) |
Jun
(22) |
Jul
(12) |
Aug
(7) |
Sep
(14) |
Oct
(26) |
Nov
(5) |
Dec
(5) |
2009 |
Jan
(10) |
Feb
(41) |
Mar
(70) |
Apr
(88) |
May
(49) |
Jun
(62) |
Jul
(34) |
Aug
(15) |
Sep
(55) |
Oct
(40) |
Nov
(67) |
Dec
(21) |
2010 |
Jan
(60) |
Feb
(17) |
Mar
(26) |
Apr
(26) |
May
(29) |
Jun
(4) |
Jul
(21) |
Aug
(21) |
Sep
(10) |
Oct
(12) |
Nov
(3) |
Dec
(19) |
2011 |
Jan
(3) |
Feb
(13) |
Mar
(8) |
Apr
(8) |
May
(17) |
Jun
(20) |
Jul
(21) |
Aug
(7) |
Sep
|
Oct
|
Nov
(9) |
Dec
(11) |
2012 |
Jan
(3) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
(14) |
Jul
(5) |
Aug
(2) |
Sep
(15) |
Oct
(2) |
Nov
(23) |
Dec
(1) |
2013 |
Jan
(8) |
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
(12) |
Nov
(10) |
Dec
(3) |
2014 |
Jan
(7) |
Feb
(14) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(11) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(1) |
Dec
(2) |
2015 |
Jan
(9) |
Feb
(7) |
Mar
(1) |
Apr
|
May
(7) |
Jun
|
Jul
(5) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
2016 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(21) |
Oct
(17) |
Nov
|
Dec
(36) |
2017 |
Jan
(6) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
2018 |
Jan
(2) |
Feb
(3) |
Mar
(3) |
Apr
(14) |
May
(2) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(6) |
Oct
(16) |
Nov
(1) |
Dec
(6) |
2019 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2025 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jair G. <jyr...@gm...> - 2010-06-20 23:03:43
|
Hi, I am developing one application that has a toolbar with seven icons, each must display a custom view in the same window when to click. My code is in http://github.com/jyr/opentumblr-cocoa/ and my example http://github.com/jyr/opentumblr-cocoa/blob/master/DashboardController.py Any suggestions? -- SIN ETIQUETAS.[ PUNTO ] http://flavors.me/jyr http://pythoncocoa.com http://opentumblr.com |
From: <jon...@mu...> - 2010-06-11 15:57:19
|
On 11 Jun 2010, at 04:45, Ronald Oussoren wrote: > > On 10 Jun, 2010, at 15:16, jon...@mu... wrote: > >> My ObjC app loads user generated PyObjC scripts using a Python NSObject subclass (see below) >> In general, errors in the Python scripts are generating application level exceptions. >> >> For instance, consider the following source file Boo.py. >> >> def funcBoo(): >> return result >> >> Dynamically loading Boo.py and calling funcBoo using the class below generates an ObjC NSException in the host app: >> Class OC_PythonObject: no such selector: _cfTypeID >> >> Assigning a value to the result variable resolves the problem. >> >> Is there a way of determining or reporting the underlying Python issue that is causing the NSException? > > Ensure that the following gets called somewhere: > > import objc; objc.setVerbose(1) > > After that PyObjC will log all exceptions when they get translated from Python to ObjC. > > That said, the exception that you are getting is not what I'd expect. I'll have to create a standalone application using your launcher to check what's going on here. > > Ronald Thanks. That helped me get to the bottom of the problem. The faulty Python was in fact generating a Python exception in the loader. My ObjC host app couldn't live with the tuple proxy class that the loader returned as a result of the Python exception. This was the source of the ObjC exception, not PyObjC itself. |
From: Ronald O. <ron...@ma...> - 2010-06-11 03:45:34
|
On 10 Jun, 2010, at 15:16, jon...@mu... wrote: > My ObjC app loads user generated PyObjC scripts using a Python NSObject subclass (see below) > In general, errors in the Python scripts are generating application level exceptions. > > For instance, consider the following source file Boo.py. > > def funcBoo(): > return result > > Dynamically loading Boo.py and calling funcBoo using the class below generates an ObjC NSException in the host app: > Class OC_PythonObject: no such selector: _cfTypeID > > Assigning a value to the result variable resolves the problem. > > Is there a way of determining or reporting the underlying Python issue that is causing the NSException? Ensure that the following gets called somewhere: import objc; objc.setVerbose(1) After that PyObjC will log all exceptions when they get translated from Python to ObjC. That said, the exception that you are getting is not what I'd expect. I'll have to create a standalone application using your launcher to check what's going on here. Ronald > > # py executor > from Foundation import * > from AppKit import * > > import imp > import sys > > class MGSPythonScriptExecutor(NSObject): > > @classmethod > def loadModuleAtPath_functionName_arguments_(self, path, func, args): > f = open(path) > try: > theResult = None > realfunc = None > taskObject = None > > # load code at path as a module > modBoo = imp.load_module('modBoo', f, path, (".py", "r", imp.PY_SOURCE)) > > try: > taskObject = modBoo.objBoo.alloc().init() > except: > taskObject = None > > # get function from object > if taskObject is not None: > > # get function > realfunc = getattr(taskObject, func, None) > > # get function from module > if realfunc is None: > # get function > realfunc = getattr(modBoo, func, None) > > # if we have a function than call it > if realfunc is not None: > > # call the function with our arguments > # we make a tuple from our list and then unpack it > theResult = realfunc(*tuple(args)) > > except Exception: > theResult = "exception in python script executor: ", sys.exc_info() > except: > theResult = "error in python script executor: ", sys.exc_info() > finally: > f.close() > > return theResult > > Regards > > Jonathan Mitchell > > Developer > Mugginsoft LLP > http://www.mugginsoft.com > > > > > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
From: <jon...@mu...> - 2010-06-10 22:43:38
|
My ObjC app loads user generated PyObjC scripts using a Python NSObject subclass (see below) In general, errors in the Python scripts are generating application level exceptions. For instance, consider the following source file Boo.py. def funcBoo(): return result Dynamically loading Boo.py and calling funcBoo using the class below generates an ObjC NSException in the host app: Class OC_PythonObject: no such selector: _cfTypeID Assigning a value to the result variable resolves the problem. Is there a way of determining or reporting the underlying Python issue that is causing the NSException? # py executor from Foundation import * from AppKit import * import imp import sys class MGSPythonScriptExecutor(NSObject): @classmethod def loadModuleAtPath_functionName_arguments_(self, path, func, args): f = open(path) try: theResult = None realfunc = None taskObject = None # load code at path as a module modBoo = imp.load_module('modBoo', f, path, (".py", "r", imp.PY_SOURCE)) try: taskObject = modBoo.objBoo.alloc().init() except: taskObject = None # get function from object if taskObject is not None: # get function realfunc = getattr(taskObject, func, None) # get function from module if realfunc is None: # get function realfunc = getattr(modBoo, func, None) # if we have a function than call it if realfunc is not None: # call the function with our arguments # we make a tuple from our list and then unpack it theResult = realfunc(*tuple(args)) except Exception: theResult = "exception in python script executor: ", sys.exc_info() except: theResult = "error in python script executor: ", sys.exc_info() finally: f.close() return theResult Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com |
From: Ronald O. <ron...@ma...> - 2010-05-26 05:33:08
|
On 24 May, 2010, at 19:56, Orestis Markou wrote: > Thank you for this. Hopefully google will pick it up for other people. > > One question - in the synthesize case, is there a convention that maps the _fido ivar to the fido property? Yes. The documentation: def synthesize(name, copy=False, readwrite=True, type=_C_ID, ivarName=None): """ Use this in a class dictionary to syntheze simple setting/setter methods. Note: this is only necessary to get propper behaviour when Key-Value coding is used and special features (like copying) are needed usage:: class MyClass (NSObject): objc.synthesize('someTitle', copy=True) """ What the documentation doesn't mention is that 'ivarName' defaults to "_" + name. BTW. synthesize will also create the ivar variable for you. Ronald > > > On 24 May 2010, at 15:43, Brice Thurin wrote: > >> Good Morning, >> >> I am new to Objective-C and PyObjc. I decided to learn Cocoa by reading the book of Aaron Hillegass, "Cocoa Programming for Mac OS X". I first tried the tried the example using only Objective-C. I am now trying to implement the same example using Python and I would like to share my finding as It took me some times to figure out how to do it, also I will appreciate some inputs as what might be a very silly way of using PyObjc. Here I would like to talk about the example of chapter 7 on key-value coding and key-value observing. At first I was a bit confused as if I was supposed to use objc.accessor or not, or if i needed to import PyObjCTools.KeyValueCoding or not, etc. >> >> I am coding on a machine running Snow Leopard and I am using XCode with the template provided on the svn. The project is called PyKVCFun. It is a python-cocoa application. Remove the appdelegate file. Create a PyAppController.py file with the template python NSObject subclass. Delete the delegate in the MainMenu.xib file and create add a new NSObject controller and set its class to PyAppController. Make sure you replace the delegate import in main.py by import PyAppController. >> >> >> STEP 1: Add an init function method to the NSObject class . >> >> It should look like this: >> >> ###### >> from Foundation import * >> import objc # Do not forget to add it as it is needed later This isn't needed in PyObjC 2.2 or later (including the version shipped with OSX). Ronald |
From: Brice T. <br...@4d...> - 2010-05-25 20:25:44
|
I believe so. Like for the other approaches. On 24 May 2010, at 18:56, Orestis Markou wrote: > Thank you for this. Hopefully google will pick it up for other people. > > One question - in the synthesize case, is there a convention that maps the _fido ivar to the fido property? > > > On 24 May 2010, at 15:43, Brice Thurin wrote: > >> Good Morning, >> >> I am new to Objective-C and PyObjc. I decided to learn Cocoa by reading the book of Aaron Hillegass, "Cocoa Programming for Mac OS X". I first tried the tried the example using only Objective-C. I am now trying to implement the same example using Python and I would like to share my finding as It took me some times to figure out how to do it, also I will appreciate some inputs as what might be a very silly way of using PyObjc. Here I would like to talk about the example of chapter 7 on key-value coding and key-value observing. At first I was a bit confused as if I was supposed to use objc.accessor or not, or if i needed to import PyObjCTools.KeyValueCoding or not, etc. >> >> I am coding on a machine running Snow Leopard and I am using XCode with the template provided on the svn. The project is called PyKVCFun. It is a python-cocoa application. Remove the appdelegate file. Create a PyAppController.py file with the template python NSObject subclass. Delete the delegate in the MainMenu.xib file and create add a new NSObject controller and set its class to PyAppController. Make sure you replace the delegate import in main.py by import PyAppController. >> >> >> STEP 1: Add an init function method to the NSObject class . >> >> It should look like this: >> >> ###### >> from Foundation import * >> import objc # Do not forget to add it as it is needed later >> >> class PyAppController(NSObject): >> >> def init(self): # objc init different than the usual __init__ of python >> >> self = super(PyAppController, self).init() # found it in one of the example of the website needed to initialise the class i believe equivalent to [super init]; of objective c. >> if self is None: return None >> >> self.setValue_forKey_(NSNumber.numberWithInt_(5), u"fido") # That is the key-value coding mechanism. >> n = self.valueForKey_(u"fido") >> NSLog(u"fido = %@", n) >> return self #required by objc. >> ###### >> >> If you run this code not too much should happen except "fido = 5" logged into the console. >> >> Step 2: Add accessor methods >> I do not think it is required but it is a good way to understand the mechanism. >> >> ###### >> def fido(self): >> NSLog(u"-fido is returning %d", self._fido) >> return self._fido >> >> def setFido_(self,x): >> NSLog(u"-setFido: is called with %d", x) >> self._fido = x >> ###### >> As you noticed, the fido variable is called using _fido (i believe other naming convention can be used but this one is quite short!), as fido is the getter method. >> So now when you run it, you should see in the console that your accessor method are called. >> >> STEP 3: Add vertical slider to the GUI >> Drop a vertical slider to your window in interface builder and make it continuous. Then bind it to the fido key of PyAppController (binding->value->Model Key Path). >> Now if you run your application you should see the setFido accessor being called as you moved the slider. >> >> STEP 4: Key-Value Observing >> Add a label to the GUI and bind its value to the fido key. >> Now run the application. And you should see the value of the label changing as you move the slider, also in the console you can see now that the two accessor are being called when you move the slider and not only the setter. However one annoying things is that the value shows as float an not integer like you might like. One way I found to solve the problem is to declare _fido at the beginning of the class like that: >> ####### >> _fido = objc.ivar.int() >> ####### >> Adding this line you can now see the label showing as int. >> >> STEP 5: Making keys observable >> The aim is now to change the variable directly. >> Add the following method to the PyAppController class: >> >> @objc.IBAction >> def incrementFido_(self,sender): >> self._fido += 1 >> NSLog(u"fido is now %d", self._fid >> Add a push button to your GUI and control-drag from the button to the PyAppController Object so the button trigger the incrementFido: action. >> I you run the code and push the button the console display the log from the button showing you that the incrementFido method is called but the label and the slider are not updated. For that to happen you need to modify your method adding two lines to notify that the key is going to change and that it has changed. >> >> @objc.IBAction >> def incrementFido_(self,sender): >> >> self.willChangeValueForKey_(u"fido") >> self._fido += 1 >> NSLog(u"fido is now %d", self._fido) >> self.didChangeValueForKey_(u"fido") >> >> Now when you run the code the increment button is working fine. >> Note: I am not sure why the getter accessor is called twice when you press the button as you might see from the console log. >> >> There are alternatives to implement the incrementFido_ method, either using key value coding: >> >> @objc.IBAction >> def incrementFido_(self,sender): >> >> n = self.valueForKey_(u"fido") >> npp = n + 1 >> self.setValue_forKey_(npp, u"fido") >> >> Note: the getter accessor is now called three time when the increment button is pushed. >> >> either using the accessor method: >> >> @objc.IBAction >> def incrementFido_(self,sender): >> >> self.setFido_(self.fido()+1) >> >> Note: the getter accessor is now called three time when the increment button is pushed. >> >> STEP 6: Using synthesize >> Also it seems there is another way of coding the same application in a much more concise way, by using objc.synthesize. >> The code for the class becomes where the setter and getter method have been replaced by synthesize, here you will not see the log in the console: >> >> from Foundation import * >> import objc >> >> class PyAppController(NSObject): >> >> objc.synthesize('fido') >> _fido = objc.ivar.int() >> >> def init(self): >> >> self = super(PyAppController, self).init() >> if self is None: return None >> >> self.setValue_forKey_(NSNumber.numberWithInt_(5) , u"fido") >> n = self.valueForKey_(u"fido") >> NSLog(u"fido = %@",n) >> return self >> >> >> @objc.IBAction >> def incrementFido_(self,sender): >> self.setFido_(self._fido + 1) >> >> Conclusion >> They must be other way to code it maybe in a more elegant way and i will be happy to hear about it. >> >> Brice >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > |
From: Orestis M. <or...@or...> - 2010-05-24 18:53:14
|
Thank you for this. Hopefully google will pick it up for other people. One question - in the synthesize case, is there a convention that maps the _fido ivar to the fido property? On 24 May 2010, at 15:43, Brice Thurin wrote: > Good Morning, > > I am new to Objective-C and PyObjc. I decided to learn Cocoa by reading the book of Aaron Hillegass, "Cocoa Programming for Mac OS X". I first tried the tried the example using only Objective-C. I am now trying to implement the same example using Python and I would like to share my finding as It took me some times to figure out how to do it, also I will appreciate some inputs as what might be a very silly way of using PyObjc. Here I would like to talk about the example of chapter 7 on key-value coding and key-value observing. At first I was a bit confused as if I was supposed to use objc.accessor or not, or if i needed to import PyObjCTools.KeyValueCoding or not, etc. > > I am coding on a machine running Snow Leopard and I am using XCode with the template provided on the svn. The project is called PyKVCFun. It is a python-cocoa application. Remove the appdelegate file. Create a PyAppController.py file with the template python NSObject subclass. Delete the delegate in the MainMenu.xib file and create add a new NSObject controller and set its class to PyAppController. Make sure you replace the delegate import in main.py by import PyAppController. > > > STEP 1: Add an init function method to the NSObject class . > > It should look like this: > > ###### > from Foundation import * > import objc # Do not forget to add it as it is needed later > > class PyAppController(NSObject): > > def init(self): # objc init different than the usual __init__ of python > > self = super(PyAppController, self).init() # found it in one of the example of the website needed to initialise the class i believe equivalent to [super init]; of objective c. > if self is None: return None > > self.setValue_forKey_(NSNumber.numberWithInt_(5), u"fido") # That is the key-value coding mechanism. > n = self.valueForKey_(u"fido") > NSLog(u"fido = %@", n) > return self #required by objc. > ###### > > If you run this code not too much should happen except "fido = 5" logged into the console. > > Step 2: Add accessor methods > I do not think it is required but it is a good way to understand the mechanism. > > ###### > def fido(self): > NSLog(u"-fido is returning %d", self._fido) > return self._fido > > def setFido_(self,x): > NSLog(u"-setFido: is called with %d", x) > self._fido = x > ###### > As you noticed, the fido variable is called using _fido (i believe other naming convention can be used but this one is quite short!), as fido is the getter method. > So now when you run it, you should see in the console that your accessor method are called. > > STEP 3: Add vertical slider to the GUI > Drop a vertical slider to your window in interface builder and make it continuous. Then bind it to the fido key of PyAppController (binding->value->Model Key Path). > Now if you run your application you should see the setFido accessor being called as you moved the slider. > > STEP 4: Key-Value Observing > Add a label to the GUI and bind its value to the fido key. > Now run the application. And you should see the value of the label changing as you move the slider, also in the console you can see now that the two accessor are being called when you move the slider and not only the setter. However one annoying things is that the value shows as float an not integer like you might like. One way I found to solve the problem is to declare _fido at the beginning of the class like that: > ####### > _fido = objc.ivar.int() > ####### > Adding this line you can now see the label showing as int. > > STEP 5: Making keys observable > The aim is now to change the variable directly. > Add the following method to the PyAppController class: > > @objc.IBAction > def incrementFido_(self,sender): > self._fido += 1 > NSLog(u"fido is now %d", self._fid > Add a push button to your GUI and control-drag from the button to the PyAppController Object so the button trigger the incrementFido: action. > I you run the code and push the button the console display the log from the button showing you that the incrementFido method is called but the label and the slider are not updated. For that to happen you need to modify your method adding two lines to notify that the key is going to change and that it has changed. > > @objc.IBAction > def incrementFido_(self,sender): > > self.willChangeValueForKey_(u"fido") > self._fido += 1 > NSLog(u"fido is now %d", self._fido) > self.didChangeValueForKey_(u"fido") > > Now when you run the code the increment button is working fine. > Note: I am not sure why the getter accessor is called twice when you press the button as you might see from the console log. > > There are alternatives to implement the incrementFido_ method, either using key value coding: > > @objc.IBAction > def incrementFido_(self,sender): > > n = self.valueForKey_(u"fido") > npp = n + 1 > self.setValue_forKey_(npp, u"fido") > > Note: the getter accessor is now called three time when the increment button is pushed. > > either using the accessor method: > > @objc.IBAction > def incrementFido_(self,sender): > > self.setFido_(self.fido()+1) > > Note: the getter accessor is now called three time when the increment button is pushed. > > STEP 6: Using synthesize > Also it seems there is another way of coding the same application in a much more concise way, by using objc.synthesize. > The code for the class becomes where the setter and getter method have been replaced by synthesize, here you will not see the log in the console: > > from Foundation import * > import objc > > class PyAppController(NSObject): > > objc.synthesize('fido') > _fido = objc.ivar.int() > > def init(self): > > self = super(PyAppController, self).init() > if self is None: return None > > self.setValue_forKey_(NSNumber.numberWithInt_(5) , u"fido") > n = self.valueForKey_(u"fido") > NSLog(u"fido = %@",n) > return self > > > @objc.IBAction > def incrementFido_(self,sender): > self.setFido_(self._fido + 1) > > Conclusion > They must be other way to code it maybe in a more elegant way and i will be happy to hear about it. > > Brice > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
From: Brice T. <br...@4d...> - 2010-05-24 13:08:35
|
Good Morning, I am new to Objective-C and PyObjc. I decided to learn Cocoa by reading the book of Aaron Hillegass, "Cocoa Programming for Mac OS X". I first tried the tried the example using only Objective-C. I am now trying to implement the same example using Python and I would like to share my finding as It took me some times to figure out how to do it, also I will appreciate some inputs as what might be a very silly way of using PyObjc. Here I would like to talk about the example of chapter 7 on key-value coding and key-value observing. At first I was a bit confused as if I was supposed to use objc.accessor or not, or if i needed to import PyObjCTools.KeyValueCoding or not, etc. I am coding on a machine running Snow Leopard and I am using XCode with the template provided on the svn. The project is called PyKVCFun. It is a python-cocoa application. Remove the appdelegate file. Create a PyAppController.py file with the template python NSObject subclass. Delete the delegate in the MainMenu.xib file and create add a new NSObject controller and set its class to PyAppController. Make sure you replace the delegate import in main.py by import PyAppController. STEP 1: Add an init function method to the NSObject class . It should look like this: ###### from Foundation import * import objc # Do not forget to add it as it is needed later class PyAppController(NSObject): def init(self): # objc init different than the usual __init__ of python self = super(PyAppController, self).init() # found it in one of the example of the website needed to initialise the class i believe equivalent to [super init]; of objective c. if self is None: return None self.setValue_forKey_(NSNumber.numberWithInt_(5), u"fido") # That is the key-value coding mechanism. n = self.valueForKey_(u"fido") NSLog(u"fido = %@", n) return self #required by objc. ###### If you run this code not too much should happen except "fido = 5" logged into the console. Step 2: Add accessor methods I do not think it is required but it is a good way to understand the mechanism. ###### def fido(self): NSLog(u"-fido is returning %d", self._fido) return self._fido def setFido_(self,x): NSLog(u"-setFido: is called with %d", x) self._fido = x ###### As you noticed, the fido variable is called using _fido (i believe other naming convention can be used but this one is quite short!), as fido is the getter method. So now when you run it, you should see in the console that your accessor method are called. STEP 3: Add vertical slider to the GUI Drop a vertical slider to your window in interface builder and make it continuous. Then bind it to the fido key of PyAppController (binding->value->Model Key Path). Now if you run your application you should see the setFido accessor being called as you moved the slider. STEP 4: Key-Value Observing Add a label to the GUI and bind its value to the fido key. Now run the application. And you should see the value of the label changing as you move the slider, also in the console you can see now that the two accessor are being called when you move the slider and not only the setter. However one annoying things is that the value shows as float an not integer like you might like. One way I found to solve the problem is to declare _fido at the beginning of the class like that: ####### _fido = objc.ivar.int() ####### Adding this line you can now see the label showing as int. STEP 5: Making keys observable The aim is now to change the variable directly. Add the following method to the PyAppController class: @objc.IBAction def incrementFido_(self,sender): self._fido += 1 NSLog(u"fido is now %d", self._fid Add a push button to your GUI and control-drag from the button to the PyAppController Object so the button trigger the incrementFido: action. I you run the code and push the button the console display the log from the button showing you that the incrementFido method is called but the label and the slider are not updated. For that to happen you need to modify your method adding two lines to notify that the key is going to change and that it has changed. @objc.IBAction def incrementFido_(self,sender): self.willChangeValueForKey_(u"fido") self._fido += 1 NSLog(u"fido is now %d", self._fido) self.didChangeValueForKey_(u"fido") Now when you run the code the increment button is working fine. Note: I am not sure why the getter accessor is called twice when you press the button as you might see from the console log. There are alternatives to implement the incrementFido_ method, either using key value coding: @objc.IBAction def incrementFido_(self,sender): n = self.valueForKey_(u"fido") npp = n + 1 self.setValue_forKey_(npp, u"fido") Note: the getter accessor is now called three time when the increment button is pushed. either using the accessor method: @objc.IBAction def incrementFido_(self,sender): self.setFido_(self.fido()+1) Note: the getter accessor is now called three time when the increment button is pushed. STEP 6: Using synthesize Also it seems there is another way of coding the same application in a much more concise way, by using objc.synthesize. The code for the class becomes where the setter and getter method have been replaced by synthesize, here you will not see the log in the console: from Foundation import * import objc class PyAppController(NSObject): objc.synthesize('fido') _fido = objc.ivar.int() def init(self): self = super(PyAppController, self).init() if self is None: return None self.setValue_forKey_(NSNumber.numberWithInt_(5) , u"fido") n = self.valueForKey_(u"fido") NSLog(u"fido = %@",n) return self @objc.IBAction def incrementFido_(self,sender): self.setFido_(self._fido + 1) Conclusion They must be other way to code it maybe in a more elegant way and i will be happy to hear about it. Brice |
From: Ronald O. <ron...@ma...> - 2010-05-21 05:45:07
|
On 20 May, 2010, at 21:52, Scott Harris wrote: > Thanks. Changing the method name to something other than action fixes the issue. Is action a bad choice for a method in general? I'd say so purely design/code smell view: 'action' doesn't communicate what the method will do (at least not unless it returns an action of some sort). That said, the crash your having is a bug in PyObjC as I expected. The bug has two levels: first of all PyObjC thinks there is an informal protocol that describes the interface of an action method because a class in AppKit defines its action method in a category. Secondly PyObjC shouldn't use its knowlegde about informal protocols to override the method signature of method that is defined in ObjC. This last bit causes the crash: your ObjC method is a method dat returns nothing ("-(void)action"), while the action method in the PyObjC metadata returns a selector ("-(SEL)action"). This causes PyObjC to treat some arbitrary value on the stack as a SEL, which is basicly a C string and that causes a EXC_BAD_ACCESS. Ronald > > -Scott > On May 15, 2010, at 11:24 AM, Ronald Oussoren wrote: > >> >> On 14 May, 2010, at 8:40, Scott Harris wrote: >> >>> I've got this obj-c object in a simple demo program: >>> >>> >>> @implementation junker >>> -(id) init >>> { >>> [super init]; >>> NSLog(@"initing"); >>> [self action]; >>> return self; >>> } >>> -(void) action >>> { >>> NSLog(@"junk"); >>> //NSBeep(); >>> } >>> @end >>> >>> I call it from Python in my App delegate like this: >>> >>> from Foundation import * >>> from AppKit import * >>> >>> class PyObjCTestAppDelegate(NSObject): >>> def applicationDidFinishLaunching_(self, sender): >>> NSLog("Application did finish launching.") >>> self.a=junker.alloc().init() >>> >>> def awakeFromNib(self): >>> NSLog("Awoke from NIB") >>> >>> @objc.IBAction >>> def buttonPress_(self, sender): >>> NSLog("Button pressed!") >>> self.a.action() >>> >>> The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange. >>> >>> Here's the console output: >>> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB >>> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing >>> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching. >>> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing >>> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk >>> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed >>> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk >>> Program received signal: “EXC_BAD_ACCESS”. >>> sharedlibrary apply-load-rules all >>> >>> Any ideas? >> >> The code looks correct, but indeed crashes. I'm looking into this, at first glance it seems that PyObjC is confused about the return type for [junker -action], and that's probably caused by the metadata files. >> >> One quick way to work around this: rename 'action' to something else. >> >> Ronald >> > |
From: Jonathan <jon...@jo...> - 2010-05-20 20:22:25
|
It's probably python getting what you're doing confused with methods common to the target-action system. I've found it to be a good idea to avoid method names that come up in AppKiDo when using bridged languages with cocoa. Cheers jonathan Saggau Happily elbows-deep in python again, if only for a couple of weeks. :) On Thu, May 20, 2010 at 3:52 PM, Scott Harris <sco...@gm...> wrote: > Thanks. Changing the method name to something other than action fixes the > issue. Is action a bad choice for a method in general? > -Scott > On May 15, 2010, at 11:24 AM, Ronald Oussoren wrote: > > On 14 May, 2010, at 8:40, Scott Harris wrote: > > I've got this obj-c object in a simple demo program: > > @implementation junker > -(id) init > { > [super init]; > NSLog(@"initing"); > [self action]; > return self; > } > -(void) action > { > NSLog(@"junk"); > //NSBeep(); > } > @end > I call it from Python in my App delegate like this: > from Foundation import * > from AppKit import * > class PyObjCTestAppDelegate(NSObject): > def applicationDidFinishLaunching_(self, sender): > NSLog("Application did finish launching.") > self.a=junker.alloc().init() > def awakeFromNib(self): > NSLog("Awoke from NIB") > @objc.IBAction > def buttonPress_(self, sender): > NSLog("Button pressed!") > self.a.action() > The funny thing is that the program crashes when I press the button that > calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep > is uncommented. Strange. > Here's the console output: > 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB > 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing > 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish > launching. > 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing > 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk > 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed > 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk > Program received signal: “EXC_BAD_ACCESS”. > sharedlibrary apply-load-rules all > Any ideas? > > The code looks correct, but indeed crashes. I'm looking into this, at first > glance it seems that PyObjC is confused about the return type for [junker > -action], and that's probably caused by the metadata files. > One quick way to work around this: rename 'action' to something else. > Ronald > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > > -- Jonathan Saggau jonathansaggau.com This amusement engaged me so much that [friends] were obliged to force me from it; and thus it is with every inclination I give into, it continues to augment, till at length it becomes so powerful, that I lose sight of everything except the favorite amusement. - Rousseau |
From: Scott H. <sco...@gm...> - 2010-05-20 19:52:47
|
Thanks. Changing the method name to something other than action fixes the issue. Is action a bad choice for a method in general? -Scott On May 15, 2010, at 11:24 AM, Ronald Oussoren wrote: > > On 14 May, 2010, at 8:40, Scott Harris wrote: > >> I've got this obj-c object in a simple demo program: >> >> >> @implementation junker >> -(id) init >> { >> [super init]; >> NSLog(@"initing"); >> [self action]; >> return self; >> } >> -(void) action >> { >> NSLog(@"junk"); >> //NSBeep(); >> } >> @end >> >> I call it from Python in my App delegate like this: >> >> from Foundation import * >> from AppKit import * >> >> class PyObjCTestAppDelegate(NSObject): >> def applicationDidFinishLaunching_(self, sender): >> NSLog("Application did finish launching.") >> self.a=junker.alloc().init() >> >> def awakeFromNib(self): >> NSLog("Awoke from NIB") >> >> @objc.IBAction >> def buttonPress_(self, sender): >> NSLog("Button pressed!") >> self.a.action() >> >> The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange. >> >> Here's the console output: >> 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB >> 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing >> 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching. >> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing >> 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk >> 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed >> 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk >> Program received signal: “EXC_BAD_ACCESS”. >> sharedlibrary apply-load-rules all >> >> Any ideas? > > The code looks correct, but indeed crashes. I'm looking into this, at first glance it seems that PyObjC is confused about the return type for [junker -action], and that's probably caused by the metadata files. > > One quick way to work around this: rename 'action' to something else. > > Ronald > |
From: Kingsley R. <kin...@gm...> - 2010-05-18 15:08:12
|
Thats really a Good news to hear. Kingsley On Tue, May 18, 2010 at 7:37 PM, Ronald Oussoren <ron...@ma...>wrote: > > On 18 May, 2010, at 12:05, Kingsley Reuben wrote: > > Hi, > > Any updates on this. > > > I've ported all extensions to py3k and am currently slowly working towards > a release. I'm fairly limited in the amount of time I can spend on > projects, and part of that time is spent on python itself (I'm also the > platform maintainer for Python's OSX port). > > Please keep in mind that all work in PyObjC and my work on Python itself is > in my free time and is completely unfunded. > > Regards, > > Ronald > > > regards, > Kingsley > > On Thu, Mar 25, 2010 at 3:58 PM, Ronald Oussoren <ron...@ma...>wrote: > >> >> On 22 Mar, 2010, at 13:05, Kingsley Reuben wrote: >> >> > Hi all, >> > >> > Am using OS X 10.6 (Snow Leopard). >> > >> > Just wanted to know whether Python 3.x is supported for FSEvents through >> PyObjC. >> >> Not yet. >> >> I've started on a python 3.x port of PyObjC but that's not finished yet >> and the FSEvents wrappers haven't been ported yet. >> >> Ronald >> > >> > regards, >> > Kings >> > >> ------------------------------------------------------------------------------ >> > Download Intel® Parallel Studio Eval >> > Try the new software tools for yourself. Speed compiling, find bugs >> > proactively, and fine-tune applications for parallel performance. >> > See why Intel Parallel Studio got high marks during beta. >> > >> http://p.sf.net/sfu/intel-sw-dev_______________________________________________ >> > Pyobjc-dev mailing list >> > Pyo...@li... >> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> >> > > |
From: Ronald O. <ron...@ma...> - 2010-05-18 14:08:10
|
On 18 May, 2010, at 12:05, Kingsley Reuben wrote: > Hi, > > Any updates on this. I've ported all extensions to py3k and am currently slowly working towards a release. I'm fairly limited in the amount of time I can spend on projects, and part of that time is spent on python itself (I'm also the platform maintainer for Python's OSX port). Please keep in mind that all work in PyObjC and my work on Python itself is in my free time and is completely unfunded. Regards, Ronald > > regards, > Kingsley > > On Thu, Mar 25, 2010 at 3:58 PM, Ronald Oussoren <ron...@ma...> wrote: > > On 22 Mar, 2010, at 13:05, Kingsley Reuben wrote: > > > Hi all, > > > > Am using OS X 10.6 (Snow Leopard). > > > > Just wanted to know whether Python 3.x is supported for FSEvents through PyObjC. > > Not yet. > > I've started on a python 3.x port of PyObjC but that's not finished yet and the FSEvents wrappers haven't been ported yet. > > Ronald > > > > regards, > > Kings > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > > Pyobjc-dev mailing list > > Pyo...@li... > > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > > |
From: Kingsley R. <kin...@gm...> - 2010-05-18 10:06:05
|
Hi, Any updates on this. regards, Kingsley On Thu, Mar 25, 2010 at 3:58 PM, Ronald Oussoren <ron...@ma...>wrote: > > On 22 Mar, 2010, at 13:05, Kingsley Reuben wrote: > > > Hi all, > > > > Am using OS X 10.6 (Snow Leopard). > > > > Just wanted to know whether Python 3.x is supported for FSEvents through > PyObjC. > > Not yet. > > I've started on a python 3.x port of PyObjC but that's not finished yet and > the FSEvents wrappers haven't been ported yet. > > Ronald > > > > regards, > > Kings > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > > Pyobjc-dev mailing list > > Pyo...@li... > > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > > |
From: Ronald O. <ron...@ma...> - 2010-05-15 17:24:39
|
On 14 May, 2010, at 8:40, Scott Harris wrote: > I've got this obj-c object in a simple demo program: > > > @implementation junker > -(id) init > { > [super init]; > NSLog(@"initing"); > [self action]; > return self; > } > -(void) action > { > NSLog(@"junk"); > //NSBeep(); > } > @end > > I call it from Python in my App delegate like this: > > from Foundation import * > from AppKit import * > > class PyObjCTestAppDelegate(NSObject): > def applicationDidFinishLaunching_(self, sender): > NSLog("Application did finish launching.") > self.a=junker.alloc().init() > > def awakeFromNib(self): > NSLog("Awoke from NIB") > > @objc.IBAction > def buttonPress_(self, sender): > NSLog("Button pressed!") > self.a.action() > > The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange. > > Here's the console output: > 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB > 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing > 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching. > 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing > 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk > 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed > 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk > Program received signal: “EXC_BAD_ACCESS”. > sharedlibrary apply-load-rules all > > Any ideas? The code looks correct, but indeed crashes. I'm looking into this, at first glance it seems that PyObjC is confused about the return type for [junker -action], and that's probably caused by the metadata files. One quick way to work around this: rename 'action' to something else. Ronald |
From: Scott H. <sco...@gm...> - 2010-05-15 00:55:49
|
Sorry is this gets posted twice. I sent it out the other night, but never saw it show up on the list. My goal was to make a simple demo program that has a NSView implemented in Python, a NSView implemented in ObjC and that demonstrates both languages calling each other all in one app. Any ideas? Thanks, -Scott On May 14, 2010, at 12:40 AM, Scott Harris wrote: > I've got this obj-c object in a simple demo program: > > > @implementation junker > -(id) init > { > [super init]; > NSLog(@"initing"); > [self action]; > return self; > } > -(void) action > { > NSLog(@"junk"); > //NSBeep(); > } > @end > > I call it from Python in my App delegate like this: > > from Foundation import * > from AppKit import * > > class PyObjCTestAppDelegate(NSObject): > def applicationDidFinishLaunching_(self, sender): > NSLog("Application did finish launching.") > self.a=junker.alloc().init() > > def awakeFromNib(self): > NSLog("Awoke from NIB") > > @objc.IBAction > def buttonPress_(self, sender): > NSLog("Button pressed!") > self.a.action() > > The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange. > > Here's the console output: > 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB > 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing > 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching. > 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing > 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk > 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed > 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk > Program received signal: “EXC_BAD_ACCESS”. > sharedlibrary apply-load-rules all > > Any ideas? > > Thanks, > -Scott |
From: Scott H. <sco...@gm...> - 2010-05-14 16:11:37
|
Thanks for the info. I installed the XCode templates and got a demo program up and running last night using the stock PyObjC. Trying out mixing ObjC and Python and calling each language from the other. It's falling into place. -Scott On May 14, 2010, at 2:35 AM, James R Eagan wrote: > Hi Scott, > > You should be able to stick with the system-supplied PyObjC for most cases. There have been some bugs fixed since that version, but for the most part, they are minor (although the definition of "minor" will depend on which libraries you need to use). > > For what it's worth, I'm still using a (mostly) stock 10.6.3 Python/PyObjC setup for all of my development. The only changes I've made are to fix a couple of bugs in py2app relating to 1) alias builds and 2) plugin builds (see below). (I believe that Ronald has already incorporated these fixes in SVN.) > > Cheers! > James > > > [1]: > Jagaroth:/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/pyt > hon/py2app $ diff -u build_app.py.orig build_app.py > --- build_app.py.orig 2009-07-01 08:26:30.000000000 +0200 > +++ build_app.py 2009-11-02 11:49:57.000000000 +0100 > @@ -1090,7 +1090,12 @@ > > # symlink python executable > execdst = os.path.join(appdir, 'Contents', 'MacOS', 'python') > - self.symlink(sys.executable, execdst) > + prefixPathExecutable = os.path.join(sys.prefix, 'bin', 'python') > + if os.path.exists(prefixPathExecutable): > + pyExecutable = prefixPathExecutable > + else: > + pyExecutable = sys.executable > + self.symlink(pyExecutable, execdst) > > # make PYTHONHOME > pyhome = os.path.join(resdir, 'lib', 'python' + sys.version[:3]) > > > [2]: > Jagaroth:/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/pyt > hon/py2app/bootstrap $ diff -u boot_plugin.py.orig boot_plugin.py > --- boot_plugin.py.orig 2006-07-11 22:31:34.000000000 +0200 > +++ boot_plugin.py 2009-11-16 13:35:27.000000000 +0100 > @@ -5,6 +5,7 @@ > base = os.environ['RESOURCEPATH'] > site.addsitedir(base) > site.addsitedir(os.path.join(base, 'Python', 'site-packages')) > + site.addsitedir(os.path.join(sys.prefix, 'Extras', 'lib', 'python')) > for script in scripts: > path = os.path.join(base, script) > __file__ = path > > > > > Le 13 mai 2010 à 21:35, Scott Harris a écrit : > >> I'm running on 10.6.2 with no other Python than the Apple supplied version. >> >> After looking a the docs and mailing list I'm still a bit confused. >> >> If I do this: "easy_install pyobjc==2.2" >> I'll end up installing 2.2 over the 2.2b3 that comes with my system and that's bad, right? >> >> So should I install another version of Python and make sure that that python is in front of the system Python in my path so that I install PyObjC against that? >> >> Can I just stick with the supplied version of PyObjC and python? What's the downside there? >> >> What's the recommended setup for PyObjC development? >> >> Thanks, >> -Scott >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > > -- > James R. Eagan > LRI — Bâtiment 490 > Université de Paris-Sud XI email: Jam...@lr... > 91405 Orsay Cedex — France web: http://www.lri.fr/~eaganj > |
From: James R E. <Jam...@lr...> - 2010-05-14 08:36:05
|
Hi Scott, You should be able to stick with the system-supplied PyObjC for most cases. There have been some bugs fixed since that version, but for the most part, they are minor (although the definition of "minor" will depend on which libraries you need to use). For what it's worth, I'm still using a (mostly) stock 10.6.3 Python/PyObjC setup for all of my development. The only changes I've made are to fix a couple of bugs in py2app relating to 1) alias builds and 2) plugin builds (see below). (I believe that Ronald has already incorporated these fixes in SVN.) Cheers! James [1]: Jagaroth:/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/pyt hon/py2app $ diff -u build_app.py.orig build_app.py --- build_app.py.orig 2009-07-01 08:26:30.000000000 +0200 +++ build_app.py 2009-11-02 11:49:57.000000000 +0100 @@ -1090,7 +1090,12 @@ # symlink python executable execdst = os.path.join(appdir, 'Contents', 'MacOS', 'python') - self.symlink(sys.executable, execdst) + prefixPathExecutable = os.path.join(sys.prefix, 'bin', 'python') + if os.path.exists(prefixPathExecutable): + pyExecutable = prefixPathExecutable + else: + pyExecutable = sys.executable + self.symlink(pyExecutable, execdst) # make PYTHONHOME pyhome = os.path.join(resdir, 'lib', 'python' + sys.version[:3]) [2]: Jagaroth:/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/pyt hon/py2app/bootstrap $ diff -u boot_plugin.py.orig boot_plugin.py --- boot_plugin.py.orig 2006-07-11 22:31:34.000000000 +0200 +++ boot_plugin.py 2009-11-16 13:35:27.000000000 +0100 @@ -5,6 +5,7 @@ base = os.environ['RESOURCEPATH'] site.addsitedir(base) site.addsitedir(os.path.join(base, 'Python', 'site-packages')) + site.addsitedir(os.path.join(sys.prefix, 'Extras', 'lib', 'python')) for script in scripts: path = os.path.join(base, script) __file__ = path Le 13 mai 2010 à 21:35, Scott Harris a écrit : > I'm running on 10.6.2 with no other Python than the Apple supplied version. > > After looking a the docs and mailing list I'm still a bit confused. > > If I do this: "easy_install pyobjc==2.2" > I'll end up installing 2.2 over the 2.2b3 that comes with my system and that's bad, right? > > So should I install another version of Python and make sure that that python is in front of the system Python in my path so that I install PyObjC against that? > > Can I just stick with the supplied version of PyObjC and python? What's the downside there? > > What's the recommended setup for PyObjC development? > > Thanks, > -Scott > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev -- James R. Eagan LRI — Bâtiment 490 Université de Paris-Sud XI email: Jam...@lr... 91405 Orsay Cedex — France web: http://www.lri.fr/~eaganj |
From: Scott H. <sco...@gm...> - 2010-05-14 06:41:03
|
I've got this obj-c object in a simple demo program: @implementation junker -(id) init { [super init]; NSLog(@"initing"); [self action]; return self; } -(void) action { NSLog(@"junk"); //NSBeep(); } @end I call it from Python in my App delegate like this: from Foundation import * from AppKit import * class PyObjCTestAppDelegate(NSObject): def applicationDidFinishLaunching_(self, sender): NSLog("Application did finish launching.") self.a=junker.alloc().init() def awakeFromNib(self): NSLog("Awoke from NIB") @objc.IBAction def buttonPress_(self, sender): NSLog("Button pressed!") self.a.action() The funny thing is that the program crashes when I press the button that calls buttonPress iff NSBeep is commented out, but runs fine if the NSBeep is uncommented. Strange. Here's the console output: 2010-05-14 00:39:23.924 PyObjCTest[99096:a0f] Awoke from NIB 2010-05-14 00:39:24.006 PyObjCTest[99096:a0f] Drawing 2010-05-14 00:39:24.069 PyObjCTest[99096:a0f] Application did finish launching. 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] initing 2010-05-14 00:39:24.070 PyObjCTest[99096:a0f] junk 2010-05-14 00:39:29.781 PyObjCTest[99096:a0f] Button Pressed 2010-05-14 00:39:29.782 PyObjCTest[99096:a0f] junk Program received signal: “EXC_BAD_ACCESS”. sharedlibrary apply-load-rules all Any ideas? Thanks, -Scott |
From: Aahz <aa...@py...> - 2010-05-14 02:08:06
|
On Tue, May 11, 2010, Ronald Oussoren wrote: > On 10 May, 2010, at 21:46, Luc Heinrich wrote: >> >> I personnally did it by patching all the setup.cfg files with an >> additional easy_install section, like this: >> >> [easy_install] >> zip_ok = 0 > > You can do this globally as well by adding these lines to > ".pydistutils.cfg" in your home directory. Any way to get that effect for regular setup.py usage? I ran into this problem building PyObjC 2.2 from source. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. |
From: Scott H. <sco...@gm...> - 2010-05-13 19:35:53
|
I'm running on 10.6.2 with no other Python than the Apple supplied version. After looking a the docs and mailing list I'm still a bit confused. If I do this: "easy_install pyobjc==2.2" I'll end up installing 2.2 over the 2.2b3 that comes with my system and that's bad, right? So should I install another version of Python and make sure that that python is in front of the system Python in my path so that I install PyObjC against that? Can I just stick with the supplied version of PyObjC and python? What's the downside there? What's the recommended setup for PyObjC development? Thanks, -Scott |
From: Luc H. <lu...@ho...> - 2010-05-11 09:55:14
|
On 11 mai 2010, at 09:44, Ronald Oussoren wrote: > You can do this globally as well by adding these lines to ".pydistutils.cfg" in your home directory. Indeed I can, but since I'm building all my dependencies in a sandbox using a script which will also run on machines other than my own I preferred not to tinker with global user settings too much. But thanks for the tip ;) -- Luc Heinrich - lu...@ho... |
From: Ronald O. <ron...@ma...> - 2010-05-11 07:44:30
|
On 10 May, 2010, at 21:46, Luc Heinrich wrote: > I personnally did it by patching all the setup.cfg files with an additional easy_install section, like this: > > [easy_install] > zip_ok = 0 You can do this globally as well by adding these lines to ".pydistutils.cfg" in your home directory. Ronald |
From: Ronald O. <ron...@ma...> - 2010-05-11 07:39:00
|
On 10 May, 2010, at 21:46, Luc Heinrich wrote: > > >> File "build/bdist.macosx-10.5-fat/egg/Foundation/__init__.py", line 10, in <module> >> File "build/bdist.macosx-10.5-fat/egg/CoreFoundation/__init__.py", line 19, in <module> >> File "objc/_bridgesupport.pyo", line 156, in initFrameworkWrapper >> File "objc/_bridgesupport.pyo", line 58, in _parseBridgeSupport > > The reason why it fails miserably is because py2app doesn't seem to know how to deal (or fail to deal correctly) with compressed Python eggs. The solution (at least for me :)) is to force PyObjC and any other library to be installed as non-compressed eggs. I personnally did it by patching all the setup.cfg files with an additional easy_install section, like this: Crap. Py2app is supposed to support zipped eggs. I'll make sure that the next release of pyobjc has 'zip_safe=False' in its setup.py files, after that I want to spend time on cleaning up and fixing py2app. Ronald |
From: Ronald O. <ron...@ma...> - 2010-05-11 07:33:20
|
On 10 May, 2010, at 23:05, Aahz wrote: > On Mon, May 10, 2010, Luc Heinrich wrote: >> >> The reason why it fails miserably is because py2app doesn't seem to >> know how to deal (or fail to deal correctly) with compressed Python >> eggs. The solution (at least for me :)) is to force PyObjC and any >> other library to be installed as non-compressed eggs. > > Ah, yes, compressed eggs, the bane of both py2app and py2exe. They both > rely on modulefinder, which is the real root of the problem. py2app doesn't use modulefinder but modulegraph, which has simular functionality to modulefinder but is slightly different. Ronald > > Thanks for posting an update! > -- > Aahz (aa...@py...) <*> http://www.pythoncraft.com/ > > f u cn rd ths, u cn gt a gd jb n nx prgrmmng. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |