pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: 1.0?

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> I've checked in a patch that adds an argument to the function that
> actually loads frameworks. This argument is a list of classnames. If
> a class is in the list it is assumed to be in the framework, and
> won't be subjected to an expensive lookup. This seems to help a
> little on my box.
> 
> Please let me know if this is an improvement.

It seems barely noticable :-( Perhaps I now get 7 or 8 bounces instead
of 8 or 9, if I really want to see it... Better than nothing, thanks!

Just

[Pyobjc-dev] [ pyobjc-Bugs-758114 ] PB Highlighting for triple-quoted strings

[SourceForge.net <no...@so...>]

Bugs item #758114, was opened at 2003-06-20 21:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=758114&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Bill Bumgarner (bbum)
Summary: PB Highlighting for triple-quoted strings

Initial Comment:
As noted by Dan Grassi, Project Builder doesn't
correctly highlight triple-quoted multi-line strings if
you use single-quotes. Doublequotes work as expected.

The pblangspec file looks correct (single- and
double-quoted strings are treated the same).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=758114&group_id=14534

Re: [Pyobjc-dev] Re: 1.0?

[Ronald O. <ous...@ci...>]

On Wednesday, Jun 18, 2003, at 22:10 Europe/Amsterdam, Ronald Oussoren 
wrote:

>
> On Wednesday, Jun 18, 2003, at 21:55 Europe/Amsterdam, Jack Jansen 
> wrote:
>
>>
>> On woensdag, jun 18, 2003, at 20:21 Europe/Amsterdam, Ronald Oussoren 
>> wrote:
>>> We already build minimally initialized classes, the problem is that 
>>> [NSBundle bundleForClass:] seems to be very expensive. That is at 
>>> least what I remembered from the previous time this came up, I think 
>>> bundleForClass did a lot of I/O for every class we look at. At the 
>>> time there were more important issues, but I think this is the major 
>>> technical issue with the bridge at the moment.
>>
>> How many bundles are we talking about, usually? Cocoa and the main 
>> application bundle? If so, then could we keep those two handy, and 
>> use [bundle classNamed: xxx] as a quick test to see whether the class 
>> is in there?
>>
>> That does assume that classNamed: is cheaper than bundleForClass:.
> It is worth testing if classNamed: is cheaper. If it is cheaper we can 
> use this method instead of bundleForClass.

It isn't. I saw no noticable improvement when switching to this method. 
I did think of an alternative:
I've checked in a patch that adds an argument to the function that 
actually loads frameworks. This argument is a list of classnames. If a 
class is in the list it is assumed to be in the framework, and won't be 
subjected to an expensive lookup. This seems to help a little on my box.

Please let me know if this is an improvement.

Ronald

[Pyobjc-dev] Fwd: [Pythonmac-SIG] PyObjC - sample code project

[Just v. R. <ju...@le...>]

Dan Grassi just posted a wonderful little PyObjC demo to the MacPython list.
Forwarding it here for those not on that list.

Just

====== Forwarded Message ======
Date: 6/20/03 12:14 AM
Received: 6/20/03 6:15 AM
From: Dan Grassi <da...@gr...>
To: pyt...@py...

Hi,

I put together a sample PyObjC application with a MVC approach.  It  
might be a useful example since I could not find one close to this.  It  
is PB centric for those who would like to go this route.  The URL is:

http://homepage.mac.com/dgrassi/.cv/dgrassi/Public/FieldGraph.dmg-link.dmg

It calculates the field pattern and RMS field of an antenna array with  
up to three elements.

I am very impressed and will get a lot of use from PyObjC -- thanks!

Dan


PS Is anyone else going to WWDC this year and would getting together be  
interesting?

====== End Forwarded Message ======

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Dinu G. <gh...@da...>]

Just van Rossum:

> NSBeginAlertSheet() returns _immediately_, and therefor your x 
> attribute
> will only be available after sheetDidEnd_etc. was called. Sheets are
> modal to the window, not the entire app, so while the sheet is up there
> the event loop continues as usual. That's why it uses callbacks instead
> of a return value...

Uhm, right, probably lack of sleep... :-/ The following will do it:

     def sayHelloAction_(self, sender):
         info = 0
         makeAlertSheet("title", "msg", info, sender.window(), self)

     def sayHelloActionContinued(self):
         print self.x

     def sheetDidEnd_returnCode_contextInfo_(self, sheet, returnCode, 
info):
         self.x = returnCode
         self.sayHelloActionContinued()

Dinu

--
Dinu C. Gherman
......................................................................
"A whole generation has grown up with the idea that it is normal
for them to have no freedom." (Richard M. Stallman)

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> I wrote:
> 
> > Surprisingly that doesn't work for me (on the latest CVS version).
> > But using objc.selector() directly does work. I'm attaching the file
> > MyAppDelegate.py which you can replace the respective file with from
> > the "Cocoa Python Application" PB template to test.
> 
> Also very strange: if I use in the same file these methods which
> try to save the return value of the sheet in a variable x for fur-
> ther use, I get an AttributeError and the app crashes before I even
> have a chance of clicking any button in the sheet itself:
> 
>      def sayHelloAction_(self, sender):
>          # adapted from same method of the "Cocoa Python Application"
PB 
> template
>          info = 0
>          makeAlertSheet("title", "msg", info, sender.window(), self)
>          print self.x
> 
>      def sheetDidEnd_returnCode_contextInfo_(self, sheet, returnCode, 
> info):
>          print "sheetDidEnd_returnCode_contextInfo_", sheet,
returnCode, 
> info
>          self.x = returnCode
> 
> I don't know which other way one can use the returnCode, since the
> NSBeginAlertSheet() function itself returns only None...

NSBeginAlertSheet() returns _immediately_, and therefor your x attribute
will only be available after sheetDidEnd_etc. was called. Sheets are
modal to the window, not the entire app, so while the sheet is up there
the event loop continues as usual. That's why it uses callbacks instead
of a return value...

Just

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Dinu G. <gh...@da...>]

I wrote:

> Surprisingly that doesn't work for me (on the latest CVS version).
> But using objc.selector() directly does work. I'm attaching the file
> MyAppDelegate.py which you can replace the respective file with from
> the "Cocoa Python Application" PB template to test.

Also very strange: if I use in the same file these methods which
try to save the return value of the sheet in a variable x for fur-
ther use, I get an AttributeError and the app crashes before I even
have a chance of clicking any button in the sheet itself:

     def sayHelloAction_(self, sender):
         # adapted from same method of the "Cocoa Python Application" PB 
template
         info = 0
         makeAlertSheet("title", "msg", info, sender.window(), self)
         print self.x

     def sheetDidEnd_returnCode_contextInfo_(self, sheet, returnCode, 
info):
         print "sheetDidEnd_returnCode_contextInfo_", sheet, returnCode, 
info
         self.x = returnCode

I don't know which other way one can use the returnCode, since the
NSBeginAlertSheet() function itself returns only None...

Dinu

--
Dinu C. Gherman
......................................................................
"Political satire became obsolete when Henry Kissinger was awarded
the Nobel Peace Prize." (Tom Lehrer)

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> Or:
> 	sheetDidEnd_returnCode_contextInfo_ = AppKit.NSEndSheetMethod(
> 		sheetDidEnd_returnCode_contextInfo_)

Surprisingly that doesn't work for me (on the latest CVS version).
But using objc.selector() directly does work. I'm attaching the file
MyAppDelegate.py which you can replace the respective file with from
the "Cocoa Python Application" PB template to test.

Dinu

Re: [Pyobjc-dev] Using Python from ObjC tutorial - Give it a try

[Ronald O. <ous...@ci...>]

On Wednesday, Jun 18, 2003, at 22:05 Europe/Amsterdam, Jack Jansen 
wrote:

>
>
>> W.r.t. loading PythonGlue: It might not be necesary to instantiate a 
>> class, you could do everything with class methods. You could even do 
>> all the work in a +load method, but as the order in which the load 
>> methods are called seems to be undefined this is a bit scary.
>
> I would really like the code to be executed *before* any nib files are 
> read. but in main.m you can't really do anything yet as AppKit hasn't 
> yet pulled itself into existence.

AFAIK any frameworks that have been linked into the executable are 
fully initialized by the time main is called, you can add the 
PythonGlue code before the call to NSApplicationMain.

Ronald

[Pyobjc-dev] One more tutorial?

[Jack J. <Jac...@cw...>]

There's one more document I want to write, basically because I feel 
that I myself would have benefitted immensely had it been available:-) 
Please let me know whether y'all think it's worth it/a waste of 
time/something to be done differently.

I was thinking of a tutorial on "How to read the PyObjC examples, for 
Python programmers". I think it's going to be different than the other 
tutorials, as no code will be written, but I think I would like to 
structure it in a "do this, see what happens?" way. I think it would be 
positioned as the second tutorial, to be done after doing the currency 
converter one.

It would explain some of the basic ideas underlying Cocoa (i.e. that a 
nib file is really frozen objects, and somewhat akin to your main 
program in other GUI kits), tell you how to use IB and maybe other 
tools to see the overall structure of your program, that sort of stuff.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] Re: 1.0?

[Ronald O. <ous...@ci...>]

On Wednesday, Jun 18, 2003, at 21:55 Europe/Amsterdam, Jack Jansen 
wrote:

>
> On woensdag, jun 18, 2003, at 20:21 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>> We already build minimally initialized classes, the problem is that 
>> [NSBundle bundleForClass:] seems to be very expensive. That is at 
>> least what I remembered from the previous time this came up, I think 
>> bundleForClass did a lot of I/O for every class we look at. At the 
>> time there were more important issues, but I think this is the major 
>> technical issue with the bridge at the moment.
>
> How many bundles are we talking about, usually? Cocoa and the main 
> application bundle? If so, then could we keep those two handy, and use 
> [bundle classNamed: xxx] as a quick test to see whether the class is 
> in there?
>
> That does assume that classNamed: is cheaper than bundleForClass:.
It is worth testing if classNamed: is cheaper. If it is cheaper we can 
use this method instead of bundleForClass.

>
> I just saw that the NSBundleDidLoadNotification gives you the names of 
> all classes from the bundle. I think this won't help us because it 
> won't help us if the bundle was loaded before our stuff was 
> initialized, right?

I don't think that the noficiation is usefull, because of the 
limitation you mentioned.

Ronald

Re: [Pyobjc-dev] Using Python from ObjC tutorial - Give it a try

[Jack J. <Jac...@cw...>]

On woensdag, jun 18, 2003, at 21:26 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> Folks,
>> the "using PyObjC in existing ObjC applications" tutorial is 
>> finished. I haven't checked it in yet,
>> but it's attached to this mail. Please give it a spin and let me know 
>> whether I should check it in.
>
> To start of I have one minor nit: the PythonGlue.{h,m,py} files are 
> not in the archive :-)

Ok, I'll try to remember adding these when I add this to CVS:-)

> W.r.t. loading PythonGlue: It might not be necesary to instantiate a 
> class, you could do everything with class methods. You could even do 
> all the work in a +load method, but as the order in which the load 
> methods are called seems to be undefined this is a bit scary.

I would really like the code to be executed *before* any nib files are 
read. but in main.m you can't really do anything yet as AppKit hasn't 
yet pulled itself into existence.

Is there any call we could do in main() that would result in our code 
being called after AppKit/Foundation are initialized, but before 
anything else happens?

> I noticed that you have to build the iTunes OSA module yourself, why 
> isn't this part of MacPython? OTOH, having a description of how you 
> build those modules is very usefull in itself.

There's lots of useful applications for which to have the OSA suite in 
some situations. I've taken the minimal approach of including only a 
select few prebuilt. For Python 2.4 I hope to have either automated the 
process, or at least streamlined it.
>
> I like this example, please add it to the repository.

Ok, will do.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] Re: 1.0?

[Jack J. <Jac...@cw...>]

On woensdag, jun 18, 2003, at 20:21 Europe/Amsterdam, Ronald Oussoren 
wrote:
> We already build minimally initialized classes, the problem is that 
> [NSBundle bundleForClass:] seems to be very expensive. That is at 
> least what I remembered from the previous time this came up, I think 
> bundleForClass did a lot of I/O for every class we look at. At the 
> time there were more important issues, but I think this is the major 
> technical issue with the bridge at the moment.

How many bundles are we talking about, usually? Cocoa and the main 
application bundle? If so, then could we keep those two handy, and use 
[bundle classNamed: xxx] as a quick test to see whether the class is in 
there?

That does assume that classNamed: is cheaper than bundleForClass:.

I just saw that the NSBundleDidLoadNotification gives you the names of 
all classes from the bundle. I think this won't help us because it 
won't help us if the bundle was loaded before our stuff was 
initialized, right?
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Jack J. <Jac...@cw...>]

On woensdag, jun 18, 2003, at 19:37 Europe/Amsterdam, Ronald Oussoren 
wrote:

> Or:
> 	sheetDidEnd_returnCode_contextInfo_ = AppKit.NSEndSheetMethod(
> 		sheetDidEnd_returnCode_contextInfo_)

Shouldn't this be flagged as being PyObjC-specific and not an Apple 
method, as we discussed some time ago?
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] Using Python from ObjC tutorial - Give it a try

[Ronald O. <ous...@ci...>]

On Wednesday, Jun 18, 2003, at 16:17 Europe/Amsterdam, Jack Jansen 
wrote:

> Folks,
> the "using PyObjC in existing ObjC applications" tutorial is finished. 
> I haven't checked it in yet,
> but it's attached to this mail. Please give it a spin and let me know 
> whether I should check it in.

To start of I have one minor nit: the PythonGlue.{h,m,py} files are not 
in the archive :-)

W.r.t. loading PythonGlue: It might not be necesary to instantiate a 
class, you could do everything with class methods. You could even do 
all the work in a +load method, but as the order in which the load 
methods are called seems to be undefined this is a bit scary.

I noticed that you have to build the iTunes OSA module yourself, why 
isn't this part of MacPython? OTOH, having a description of how you 
build those modules is very usefull in itself.

I like this example, please add it to the repository.

>
> Unlike the other tutorial this one doesn't contain the finished 
> product, as I'm not sure we can do this if I look at the Apple 
> license. The positive point is that this makes the tutorial tiny:-)
> <tutorial_embed.tgz>

I have no idea if we can distribute a modified Apple example. I don't 
think this is too bad.

Ronald

[Pyobjc-dev] Re: 1.0?

[Ronald O. <ous...@ci...>]

On Wednesday, Jun 18, 2003, at 20:00 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> I think this is related to finding all classes for the frameworks when
>> loading. I'm going to test if this is really true. It it is true we
>> need to add a module-like object to sys.modules when someone imports
>> Foundation/AppKit/.... That object should initialize classes only when
>> someone tries to use them, instead of always initializing all classes.
>> E.g. it will have a __getattr__ like this:
>>
>>   def  __getattr__(self, name):
>>       cls = objc.lookUpClass(name)
>>       if definedInBundle(self.__bundle, cls):
>>           setattr(self, name, cls)
>>           return cls
>>       else:
>>           raise ValueError, "No such attribute"
>>
>> Additional work is needed because of 'from AppKit import *', if
>> someone accesses __all__ we still have to find all classes at once.
>
> Quick idea: why not use a static list of class names, if that can save
> us time?
That is a bit risky, if the __all__ contains names that are not 
available you'll get an import-error
when doing an 'import *'. Maybe we can find an easy way to detect what 
classes are available, it will
probably suffice to do something like this:

CLASSNAMES=(
	# 10.1
	( 'NSObject', ... ),
	# 10.2
	( ... ),
	# ...
)
__all__ = []

for nameList in CLASSNAMES:
	try:
		objc.lookUpClass(nameList[0])
		all.extend(nameList)
	except objc.error:
		pass

E.g. probe for one of the classes added in a release and then add all 
classes defined in that release.
That should be a lot cheaper than what we currently do.

>
> Something in between: make __all__ a static list, but have the
> __getattr__ do a dynamic lookup anyway if the name isn't in the list.
>
> I noticed that for even minorly complex apps "from AppKit import *" is
> indispensible, so I don't think a solution that only works if you
> _don't_ do that is out of the question.
>
> To what extent could class objects be lazy? Ideal would be if
>
>     from AppKit import NSSomeClass
>
> was really cheap, and that the class was only fully initialized if it
> was used (subclasses or instantiated).

We already build minimally initialized classes, the problem is that 
[NSBundle bundleForClass:] seems to be very expensive. That is at least 
what I remembered from the previous time this came up, I think 
bundleForClass did a lot of I/O for every class we look at. At the time 
there were more important issues, but I think this is the major 
technical issue with the bridge at the moment.

Ronald

[Pyobjc-dev] 1.0 and beyond

[Ronald O. <ous...@ci...>]

On Tuesday, Jun 17, 2003, at 00:00 Europe/Amsterdam, Jack Jansen wrote:

> First off, I suggest taking this discussion to the list. Feel free to 
> repost this if you agree.

I'll do that.

>
> On maandag, jun 16, 2003, at 22:37 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> Hi,
>>
>> I think it is time to start planning for a 1.0 release. I'd like to 
>> get this out before Python 2.3, but I have no idea when that will be 
>> released.
>
> There's something to be said both for a pre-2.3 release and for a 
> post-2.3 release. In the first case I think we should reserve the 
> version "PyObjC 1.1" for a version that is functionally equivalent to 
> 1.0, with only 2.3 compatibility and bugs fixed. Or maybe 1.0.1 is a 
> better version number, sticking to the Python version numbering 
> scheme. Hmm, no, framework-Python compatibility is a feature, I guess.

In view of our public-relations effort, doing a 1.1 after the Python 
2.3 release would be better than calling it 1.0.1. I think we should 
reserve x.y.1 releases for bugfix-only releases.

>
>> As always the main problem is documentation, we need to clean up 
>> what's there, add a more complex tutorial (maybe a document-based 
>> application) and add (better) documentation on how to manage projects 
>> (how do I add files to a PB project, how does buildapp.py work, ...).
>
> The main problem I have with the current stuff is the ramp-up time. 
> That's also what I try to spend my PyObjC time on (so if people think 
> I should spend it differently let me know). I think that with the 
> tutorial I did for 0.9 we have a reasonable introduction for people 
> coming from a Python background, the other tutorial I want to do 
> (embedding Python in an existing ObjC application) should have the 
> same function to people with an ObjC/PB background.
>
> But I don't think tutorials by themselves are enough: people have to 
> be led towards them. Which means the documentation, even what little 
> there is, has to be organized and be inviting to read. Unfortunately 
> Dinu's WikiWiki doesn't seem to be going anywhere:-( probably due to 
> more people sharing my (current) inability to use WikiWiki for useful 
> work.
>
> So, we need to tackle Documentation/index.html. I would suggest 
> sections Tutorials, Examples, Implementation notes, On-line resources. 
> I think that covers what we have at the moment. Especially the 
> examples section is important, as this is where most of our 
> documentation is currently hidden. I think there should be one page 
> (or one section in index.html) which explains *all* examples: a 
> paragraph per example explaining what the example does and (more 
> importantly) what you will learn by examining it. This needs to be 
> close together for all the examples, so that if people want to start 
> doing something new they have a starting place.
>
>> What I'd also like to do before 1.0 is adding the examples to the 
>> website, do you have any ideas on
>> how to do that? Are there good scripts for converting python source 
>> files to pretty-printed HTML
>> files? I'm thinking of creating a home page for every example, with a 
>> link to tarball containing the entire example, a description of what 
>> the example does, a screenshot and links to pretty-printed Python 
>> sources. Some way to visualize the NIB contents would also be nice.
>
> I'm not sure about this one, maybe because I can't see the point. If 
> it's for "advertising purposes", i.e. to lure people into downloading 
> the stuff, then some simple Python code should be good enough 
> (pretty-printed, indeed). The next thing I would add is a .dmg that 
> will install out-of-the-box without installing PyObjC, but this is 
> probably going to be big and hairy.
>
> I can't see why people would want to download examples when they 
> already have them in the PyObjC distribution, or were you planning to 
> not distribute them in there? I don't think I like that idea (i.e. if 
> this is what you mean please convince me:-)

There is one good reason for adding a tarball for the examples: If we 
start updating the examples on the website between releases. I thought 
that having the NIBs and source available in a downloadable format 
would be usefull, but your right: those are not very usefull without 
the rest of PyObjC.

I still think we should try to add a visualisation of the NIB 
structure, as you noticed before the NIB is a substantial part of GUI 
code and the Python code may be hard to understand without 
understanding how the NIB(s) is/are structured.

>
>> On the non-documentation side:
> My feeling is all these can wait, they're good candidates for a 1.2 
> (or 1.1) release that can try to get some more press coverage. 
> Especially in the first (say) year it would be good to do releases 
> fairly often (every 2-3 months?), as every release is a chance to get 
> coverage on the apple developer mailing list and so.

I keep forgetting about "public-relations", and keep trying to get 
everything completely right before doing releases. I do foresee a 
problem w.r.t. doing releases every 2 months: We'll run out of our 
todo-list pretty soon. We can, and probably should, expand our scopy a 
little by adding usefull (development) tools (like an embeddable 
object/class browser). That should keep us going for a while.

>> * Installation cleanup
>>   - Installer needs work (see bug on SF)
>>   - README.txt needs to be synced with reality
>>   - MANIFEST should be a MANIFEST.in
>>   - Is installing in /Library/Developer really what we want?
>
> These *do* need to be solved, indeed.

None of these are difficult, other than the last. It might be usefull 
to wait for WWDC before deciding on the last item, maybe Apple will be 
fixing the problems we're having with our current release in the next 
release of the DevTools.

>
>> Post 1.0:
>
> I have another one:
> * PyObjC runtime-only installer, or instructions on how to do this. 
> This is so developers can push this on to end-users.

I'm not sure if this is generally usefull beyond in-house development. 
If you want to distribute applications/scripts based on PyObjC you 
should really build standalone applications. That said, we should at 
least document what it the minimal subset of PyObjC that is needed for 
running applications (e.g. only the site-packages/PyObjC tree, except 
the test packages) and how you extract that from a "normal" 
installation.

Ronald

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

>   sheetDidEnd_returnCode_contextInfo_ = AppKit.NSEndSheetMethod(
>       sheetDidEnd_returnCode_contextInfo_)

That one is so new I hadn't even digested it... Thanks!

Just

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Ronald O. <ous...@ci...>]

On Wednesday, Jun 18, 2003, at 17:11 Europe/Amsterdam, Just van Rossum 
wrote:

> Dinu Gherman wrote:
>
>> I reinstalled from CVS (after SF access troubles), but it's still
>> not clear to me what the code for a void pointer should be. Isn't
>> there some example to point to? The list archives mention this
>> issue specifically for sheets, but also don't give any sample
>> snippets. The code I posted before would make a good start for
>> a sample, maybe.
>
> Not tested:
>
>     def sheetDidEnd_returnCode_contextInfo_(self,
>             sheet, returnCode, info):
>         ...
>     sheetDidEnd_returnCode_contextInfo_ = objc.selector(
>             sheetDidEnd_returnCode_contextInfo_, signature="v@:@ii")
>
>
Or:
	sheetDidEnd_returnCode_contextInfo_ = AppKit.NSEndSheetMethod(
		sheetDidEnd_returnCode_contextInfo_)

Ronald

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> > NSSelectorFromString() does nothing in PyObjC, just use the string,
> > or a method object.
> 
> I've used NSSelectorFromString() before and it seemed to work, but in
> this case none of this works.

NSSelectorFromString() surely "works", but it does nothing:

  >>> sel = "foo"
  >>> NSSelectorFromString(sel) is sel
  True
  >>> 

> I reinstalled from CVS (after SF access troubles), but it's still
> not clear to me what the code for a void pointer should be. Isn't
> there some example to point to? The list archives mention this
> issue specifically for sheets, but also don't give any sample
> snippets. The code I posted before would make a good start for
> a sample, maybe.

Not tested:

    def sheetDidEnd_returnCode_contextInfo_(self,
            sheet, returnCode, info):
        ...
    sheetDidEnd_returnCode_contextInfo_ = objc.selector(
            sheetDidEnd_returnCode_contextInfo_, signature="v@:@ii")


Just

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Dinu G. <gh...@da...>]

Just van Rossum:

> NSSelectorFromString() does nothing in PyObjC, just use the string, or=20=

> a
> method object.

I've used NSSelectorFromString() before and it seemed to work, but
in this case none of this works.

> Re. you question:
> a) Make sure you run PyObjC from CVS
> b) check the archives, this was recently discussed: you need to =
specify
> the signature of your callbacks with objc.selector().

I reinstalled from CVS (after SF access troubles), but it's still
not clear to me what the code for a void pointer should be. Isn't
there some example to point to? The list archives mention this
issue specifically for sheets, but also don't give any sample
snippets. The code I posted before would make a good start for
a sample, maybe.

Dinu

--
Dinu C. Gherman
......................................................................
"Un jour le jour viendra o=F9 le jour ne viendra pas." (Paul Val=E9ry)

Re: [Pyobjc-dev] EuroPython plug

[tmk <li...@ne...>]

On Wednesday, Jun 18, 2003, at 15:59 Europe/Brussels, tmk wrote:

> I'll be there too (at leas on friday)

I meant to write "at least on Wednesday" (thanks Jack!)

= tmk =

Re: [Pyobjc-dev] Using Python from ObjC tutorial - Give it a try

[Jack J. <Jac...@cw...>]

Folks,
the "using PyObjC in existing ObjC applications" tutorial is finished. 
I haven't checked it in yet,
but it's attached to this mail. Please give it a spin and let me know 
whether I should check it in.

Unlike the other tutorial this one doesn't contain the finished 
product, as I'm not sure we can do this if I look at the Apple license. 
The positive point is that this makes the tutorial tiny:-)

Re: [Pyobjc-dev] EuroPython plug

[tmk <li...@ne...>]

I'll be there too (at leas on friday)

= tmk =

On Wednesday, Jun 18, 2003, at 11:29 Europe/Brussels, Etienne Posthumus 
wrote:

>
> On Wednesday, Jun 18, 2003, at 11:01 Europe/Amsterdam, Just van Rossum 
> wrote:
>> nice to get together sometime to chat about PyObjC. So: if you're 
>> going
>> to EuroPython, post a note here; if there's more than the four of us
>> wanting to get together we should perhaps organize something...
>
> I will be going too, so count me in.
>
> gr.
>
> EP

Re: [Pyobjc-dev] NSBeginAlertSheet trouble

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

>      dismissSel = 
> NSSelectorFromString("sheetDidDismiss:returnCode:contextInfo:")

NSSelectorFromString() does nothing in PyObjC, just use the string, or a
method object.

Re. you question:
a) Make sure you run PyObjC from CVS
b) check the archives, this was recently discussed: you need to specify
the signature of your callbacks with objc.selector().

Just