pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

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

Bob Ippolito wrote:

> I've been meaning to develop a CFRunLoop reactor for Twisted for
> months now.  Basically, you would be replacing the select() mechanism
> with something that used CFRunLoop, CFSocket (can probably use the
> existing functionality and just have the CFSocket use the fileno from
> them), and CFTimer.  Unfortunately, not all of this stuff is wrapped
> in PyObjC or Python 2.3 yet so I'm expecting it to entail a fair
> amount of pain-in-the-ass C code with lots of structures and
> callbacks into Python (yay CFSocket).

I don't know anything about how twisted reactors work internally, but
since Cocoa has pretty decent support for async I/O, wouldn't it be an
option to use this instead of going all the way down to CFRunLoop? I'm
thinking of these NSFileHandle methods:

- acceptConnectionInBackgroundAndNotify 
- readInBackgroundAndNotify 
- readToEndOfFileInBackgroundAndNotify 
- waitForDataInBackgroundAndNotify 

and the notifications that go with them.

Using any of the above will actually cause a thread to be spawned, but
that's not visible from user code. I wonder though, does Cocoa spawn a
new thread for each NSFileHandle, or will it use _one_ (possibly
select-based) thread for all of them?

Just

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

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

On Friday, Jun 13, 2003, at 15:28 Europe/Amsterdam, Bob Ippolito wrote:
>
> I've been meaning to develop a CFRunLoop reactor for Twisted for 
> months now.  Basically, you would be replacing the select() mechanism 
> with something that used CFRunLoop, CFSocket (can probably use the 
> existing functionality and just have the CFSocket use the fileno from 
> them), and CFTimer.  Unfortunately, not all of this stuff is wrapped 
> in PyObjC or Python 2.3 yet so I'm expecting it to entail a fair 
> amount of pain-in-the-ass C code with lots of structures and callbacks 
> into Python (yay CFSocket).

If you're going to wrap CFSocket/CFRunLoop you may want to check how 
Jack uses bgen and use that.

Ronald

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

[Bob I. <bo...@re...>]

On Friday, Jun 13, 2003, at 05:25 America/New_York, Just van Rossum 
wrote:

> That said, I feel quite strongly that any networking Cocoa app should
> either use asynchronous I/O or threads, which complicates the matter
> quite a bit.

Me too, it makes Python/PyObjC look really bad if we offer spinning 
beach balls with an unresponsive UI.

>
> It's possible to run a twisted reactor (= twisted event loop) in a
> different thread (I've briefly played with that, works like a charm). 
> It
> *might* be possible to build a twisted reactor that's integrated with
> the main Cocoa event loop, but that is likely quite hard. The
> WebServicesTool demo uses xmlrpclib in a worker thread (in CVS at 
> least,
> I recently did a lot of work on it), but the complicatated thing about
> it is that as soon as you use Cocoa stuff from a different thread, you
> have to deal with autorelease pools. I've found it impossible to do 
> even
> the simplest Cocoa things (eg obj.performSelectorOnMainThread_etc.) in
> PyObjC without implicitly creating autoreleased objects, so you don't
> really get around wrapping your code in
> NSAutoreleasePool.pyobjcPushPool() / NSAutoreleasePool.pyobjcPopPool()
> blocks. See WebServicesTool for how that's done.

I've been meaning to develop a CFRunLoop reactor for Twisted for months 
now.  Basically, you would be replacing the select() mechanism with 
something that used CFRunLoop, CFSocket (can probably use the existing 
functionality and just have the CFSocket use the fileno from them), and 
CFTimer.  Unfortunately, not all of this stuff is wrapped in PyObjC or 
Python 2.3 yet so I'm expecting it to entail a fair amount of 
pain-in-the-ass C code with lots of structures and callbacks into 
Python (yay CFSocket).

That said, if I find the time in the near future, it should be in a 
late release of Twisted 1.0.X or an early release of Twisted 1.1.X.  
I'll make a post to this list when it's in Twisted CVS in case anyone 
wants to play with it.  If anyone wants to wrap more of CoreFoundation 
for Python in the meantime, I surely wouldn't complain :)

-bob

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

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

Okay, a wholly different idea from the currency one: take the 
SimpleComboBox example from /Developer/Examples/Appkit. This 
demonstrates a combo-box, but what we use is the fact that the 
application pretends to be a CD collection note taking tool.

We could add a button "Ask iTunes", which would fire up Python code 
that uses Python's OSA stuff to ask iTunes for the currently playing 
artist and album.

Cons: I'm not sure the Python OSA stuff will work in a Cocoa app, won't 
work easily under 2.2 (no gensuitemodule, probably bugs in Carbon.AE 
too), the gensuitemodule song-and-dance may be a bit involved.
Pro: shows off OSA stuff too.

Comments?
--
Jack Jansen, <Jac...@cw...>, 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: FYI: Open Source Scripting Layer For Cocoa

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

Ronald Oussoren wrote:

> > Ok, that's nice for a more involved example, but not for "embedding 
> > Python in ObjC 101". Too ba, I'll try and come up with something 
> > else:-)
> 
> There is an XML-RPC library in 2.2 and 2.3, xmlrpc.org lists a number 
> of public services (from a currentTime function at Userland to Meercat 
> at O'Reilly).

The WebServicesTool example demonstrates xmlrpc already quite well.
However, it's a rather elaborate demo, so a simpler one would be very
useful as well.

That said, I feel quite strongly that any networking Cocoa app should
either use asynchronous I/O or threads, which complicates the matter
quite a bit.

It's possible to run a twisted reactor (= twisted event loop) in a
different thread (I've briefly played with that, works like a charm). It
*might* be possible to build a twisted reactor that's integrated with
the main Cocoa event loop, but that is likely quite hard. The
WebServicesTool demo uses xmlrpclib in a worker thread (in CVS at least,
I recently did a lot of work on it), but the complicatated thing about
it is that as soon as you use Cocoa stuff from a different thread, you
have to deal with autorelease pools. I've found it impossible to do even
the simplest Cocoa things (eg obj.performSelectorOnMainThread_etc.) in
PyObjC without implicitly creating autoreleased objects, so you don't
really get around wrapping your code in
NSAutoreleasePool.pyobjcPushPool() / NSAutoreleasePool.pyobjcPopPool()
blocks. See WebServicesTool for how that's done.

Just

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

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

On Friday, Jun 13, 2003, at 10:51 Europe/Amsterdam, Jack Jansen wrote:

>
> On Friday, Jun 13, 2003, at 01:21 Europe/Amsterdam, Bob Ippolito wrote:
>
>>>>> Well, if none of the online currency exchange rate sites let you
>>>>> scrape the going rate, you could always fake one that returns a 
>>>>> random
>>>>> rate within some range and scrape that.  Not as good as the Real
>>>>> Thing, but it might do.
>>>>
>>>> See the demo services at.....
>>>>
>>>>     http://xmethods.com/
>>>>
>>>> .... as any of them could easily be wrapped by a Cocoa/Python app.
>>>
>>> Ah, brilliant! There's a currency converter in there.
>>>
>>> Now the problem has been replaced by a new one: does anyone here 
>>> know how to talk to a soap service from Python, and do we have all 
>>> the necessary tools available in a standard Python installation?
>>
>> Python does not come with any SOAP stuff.  However, Twisted also does 
>> SOAP and there's also a couple blocking implementations at: 
>> http://pywebsvcs.sourceforge.net/
>
> Ok, that's nice for a more involved example, but not for "embedding 
> Python in ObjC 101". Too ba, I'll try and come up with something 
> else:-)

There is an XML-RPC library in 2.2 and 2.3, xmlrpc.org lists a number 
of public services (from a currentTime function at Userland to Meercat 
at O'Reilly).

Ronald

Re: [Pyobjc-dev] Help in bundling our PyObjC app?

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

On Friday, Jun 13, 2003, at 03:47 Europe/Amsterdam, Gary Robinson wrote:

> Our application will be running a couple of separate "slave" straight 
> Python
> (not Cocoa) scripts to handle some asynchronous tasks. Currently these
> scripts are started and managed with the popen2.Popen4 class.
>
> These slave scripts have to use a version of Python compiled to have 
> SSL
> enabled. So they can't use the stock Python.
>
> I'm wondering if anyone has advice as to how we should put our 
> Cocoa-Python
> app together with these separate scripts in a package for the user.
>
> I envision a bundle that contains the main app and the separate 
> scripts in a
> folder on disk; these all appear to be one unit to the user if I 
> understand
> bundles correctly.
>
> Since the separate scripts need an SSL-enabled Python, is there some 
> way to
> include that Python in the bundle so that the scripts can share it? Or 
> must
> each such script have the SSL Python separately merged into it?

I think (but haven't tried) that you don't need a specially built Python
to enable SSL support, you only need a specially built _socketmodule.so 
extension
module. You can probably put this somewhere in the bundle, but this is 
Advanced
Bundlebuilder so someone else will have to provide the details.

> Question 2:
>
> The bundlebuilder.py script includes the following comment:
>
> # The
> # bootstrapping script fires up the interpreter with the right
> # arguments. os.execve() is used as OSX doesn't like us to
> # start a real new process.
>
> This comment made me feel concerned about our use of popen2.Popen4,
> mentioned above, to start "real new processes". We have had no 
> problems in
> our internal testing, but does anyone know of anything we should worry 
> about
> with this?

Don't worry, the comment doesn't apply in your case. It should be 
clarified.

What the comment tries to say is that the unix process that was started 
when the
user double-clicked the application (and which runs the bootstrap 
script) must be
the same process that later connects to the window manager, otherwise 
the
OSX magic for window manager access doesn't work. This bootstrap code 
ensures that
this is the case for your Cocoa code. Any process you fork off after 
that is a
normal unix process again, i.e. doesn't have access to the window 
manager. But in
your case that is exactly what you want, as your scripts are straight 
python
without any Cocoa code.
--
Jack Jansen, <Jac...@cw...>, 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: FYI: Open Source Scripting Layer For Cocoa

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

On Friday, Jun 13, 2003, at 01:21 Europe/Amsterdam, Bob Ippolito wrote:

>>>> Well, if none of the online currency exchange rate sites let you
>>>> scrape the going rate, you could always fake one that returns a 
>>>> random
>>>> rate within some range and scrape that.  Not as good as the Real
>>>> Thing, but it might do.
>>>
>>> See the demo services at.....
>>>
>>>     http://xmethods.com/
>>>
>>> .... as any of them could easily be wrapped by a Cocoa/Python app.
>>
>> Ah, brilliant! There's a currency converter in there.
>>
>> Now the problem has been replaced by a new one: does anyone here know 
>> how to talk to a soap service from Python, and do we have all the 
>> necessary tools available in a standard Python installation?
>
> Python does not come with any SOAP stuff.  However, Twisted also does 
> SOAP and there's also a couple blocking implementations at: 
> http://pywebsvcs.sourceforge.net/

Ok, that's nice for a more involved example, but not for "embedding 
Python in ObjC 101". Too ba, I'll try and come up with something else:-)
--
Jack Jansen, <Jac...@cw...>, 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] NSRect, structs

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

Ronald Oussoren wrote:

> > I need to make an NSRect.  I know there is an NSMakeRect function,
> > but it doesn't seem to be in Foundation or AppKit.  I have tried
> > making an NSObject and assigning it attributes, but no luck there:
> > The bridge expects a "struct."  Any ideas for what I should do?
> 
> myrect = ((x, y), (h, w))
> 
> If you're using CVS:
> 
> myrect = AppKit.NSMakeRect(x, y, h, w)

It's good to have this to avoid some confusion for ObjC programmers, but
as you can see it's not really an improvement...

> Structs are represented as tuples when using PyObjC.

As are NSPoint, NSSize, NSRange and probably a few others.

Just

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

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

On Thursday, Jun 12, 2003, at 22:15 Europe/Amsterdam, Jack Jansen wrote:

>
> On woensdag, jun 11, 2003, at 21:34 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>
>> On Wednesday, Jun 11, 2003, at 15:31 US/Eastern, Ronald Oussoren 
>> wrote:
>>> We could warn about the signatures when one of the beginSheet 
>>> methods is called (better yet, make it an error when the signature 
>>> is not correct). How many of such callback API's are there, is it 
>>> just sheets or are there other API's that do callbacks to aritrary 
>>> methods with a 'difficult' signature?
>>
>> There aren't many, but that set may change over time... and, 
>> certainly, third parties can (and have) modeled their class design 
>> after Apple's.
>
> All the potential problem cases would be where a selector is passed 
> from Python to ObjC, right? Could we implement a mechanism (in the C 
> code) where all selectors can optionally be checked for correct 
> signature if a Python method is passed, and then expose a call to 
> Python where you can turn this check on?
>
> We then use this call to tell pyobjc "By the way, the selector passed 
> as the Nth parameter to beginSheet_bla_bla_bla should have signature 
> bla bla bla". Third parties could add this call too.
>
> The only problem (and a big problem, at least I don't see a simple 
> solution, but maybe someone else does) is how to refer to "the 
> selector passed as the Nth parameter to beginSheet_bla_bla_bla".

There's one problem with this: Selectors are basicly strings, you can 
also use method references in Python but that is only sugar. The method 
that you use to pass the selector to the object that will perform the 
callback need not be the same as the method that you use to pass the 
target. An example of this are the setTarget: and setAction: methods of 
controls.

Ronald

Re: [Pyobjc-dev] NSRect, structs

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

On Friday, Jun 13, 2003, at 02:44 Europe/Amsterdam, Sean Gilbertson 
wrote:

> Hello all,
>
> 	I need to make an NSRect.  I know there is an NSMakeRect function, 
> but it doesn't seem to be in Foundation or AppKit.  I have tried 
> making an NSObject and assigning it attributes, but no luck there: The 
> bridge expects a "struct."  Any ideas for what I should do?

myrect = ((x, y), (h, w))

If you're using CVS:

myrect = AppKit.NSMakeRect(x, y, h, w)

Structs are represented as tuples when using PyObjC.

Ronald

[Pyobjc-dev] Help in bundling our PyObjC app?

[Gary R. <gro...@tr...>]

Hello,

I have two questions and would be grateful for help...

Question 1:

We're creating an OS X app with PyObjC.

We have never created an OS X bundle before so we are quite the newbies in
this regard. We have also never used python's freeze or other
executable-generating capabilities. So our questions are going to be pretty
naive. In fact we are just at the outset of doing this packaging work, and
at this point are just looking for general guidance for how to go about it
so that our learning time will be spent efficiently.

Our application will be running a couple of separate "slave" straight Python
(not Cocoa) scripts to handle some asynchronous tasks. Currently these
scripts are started and managed with the popen2.Popen4 class.

These slave scripts have to use a version of Python compiled to have SSL
enabled. So they can't use the stock Python.

I'm wondering if anyone has advice as to how we should put our Cocoa-Python
app together with these separate scripts in a package for the user.

I envision a bundle that contains the main app and the separate scripts in a
folder on disk; these all appear to be one unit to the user if I understand
bundles correctly.

Since the separate scripts need an SSL-enabled Python, is there some way to
include that Python in the bundle so that the scripts can share it? Or must
each such script have the SSL Python separately merged into it?


Question 2:

The bundlebuilder.py script includes the following comment:

# The
# bootstrapping script fires up the interpreter with the right
# arguments. os.execve() is used as OSX doesn't like us to
# start a real new process.

This comment made me feel concerned about our use of popen2.Popen4,
mentioned above, to start "real new processes". We have had no problems in
our internal testing, but does anyone know of anything we should worry about
with this?


Many thanks in advance for any and all help!

--Gary

-- 
<http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] NSRect, structs

[Sean G. <pr...@cf...>]

All,

	For reference purposes, I believe the solution to my problem is that, 
for NSRects, the bridge looks for a tuple of two tuples: ( ( x, y ), ( 
height, width ) ).  I was able to use Foundation.NSRectFromString, as 
well, in the following way:

 >>> Foundation.NSRectFromString( "x = 0 y = 10 width = 20 height = 45" )
((0.0, 10.0), (20.0, 45.0))

	Anyway, I am not going to pursue my original goal for now, which was 
using NSProgressIndicators in the NSCells in NSTableViews, by returning 
them through the "value" function of a subclass of NSTableDataSource.  
I may pursue this later, so if anyone can point to some documents or 
examples (whatever language, not specifically python), I'd be grateful.

Thanks,
	Sean


On Thursday, June 12, 2003, at 08:44  PM, Sean Gilbertson wrote:

> Hello all,
>
> 	I need to make an NSRect.  I know there is an NSMakeRect function, 
> but it doesn't seem to be in Foundation or AppKit.  I have tried 
> making an NSObject and assigning it attributes, but no luck there: The 
> bridge expects a "struct."  Any ideas for what I should do?
>
> Thanks,
> 	Sean
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] NSRect, structs

[Sean G. <pr...@cf...>]

Hello all,

	I need to make an NSRect.  I know there is an NSMakeRect function, but 
it doesn't seem to be in Foundation or AppKit.  I have tried making an 
NSObject and assigning it attributes, but no luck there: The bridge 
expects a "struct."  Any ideas for what I should do?

Thanks,
	Sean

Re: [Pyobjc-dev] Re: FYI: Open Source Scripting Layer For Cocoa

[Bob I. <bo...@re...>]

On Thursday, Jun 12, 2003, at 15:59 America/New_York, Jack Jansen wrote:

>
> On woensdag, jun 11, 2003, at 20:13 Europe/Amsterdam, bb...@ma...  
> wrote:
>
>> On Wednesday, Jun 11, 2003, at 06:50 US/Eastern, Michael Hudson wrote:
>>> Well, if none of the online currency exchange rate sites let you
>>> scrape the going rate, you could always fake one that returns a  
>>> random
>>> rate within some range and scrape that.  Not as good as the Real
>>> Thing, but it might do.
>>
>> See the demo services at.....
>>
>>     http://xmethods.com/
>>
>> .... as any of them could easily be wrapped by a Cocoa/Python app.
>
> Ah, brilliant! There's a currency converter in there.
>
> Now the problem has been replaced by a new one: does anyone here know  
> how to talk to a soap service from Python, and do we have all the  
> necessary tools available in a standard Python installation?

Python does not come with any SOAP stuff.  However, Twisted also does  
SOAP and there's also a couple blocking implementations at:  
http://pywebsvcs.sourceforge.net/

With SOAPpy (which I think bbum used, perhaps an earlier version) you  
would do something like this:
 >>> from SOAPpy import WSDL
 >>> proxy =  
WSDL.Proxy("http://www.xmethods.net/sd/2001/ 
CurrencyExchangeService.wsdl") # this blocks
 >>> print proxy.getRate(country1='us', country2='canada') # so does this
0.7414

-bob

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

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

On donderdag, jun 12, 2003, at 23:05 Europe/Amsterdam, Ronald Oussoren 
wrote:

>> All the potential problem cases would be where a selector is passed 
>> from Python to ObjC, right? Could we implement a mechanism (in the C 
>> code) where all selectors can optionally be checked for correct 
>> signature if a Python method is passed, and then expose a call to 
>> Python where you can turn this check on?
>>
>> We then use this call to tell pyobjc "By the way, the selector passed 
>> as the Nth parameter to beginSheet_bla_bla_bla should have signature 
>> bla bla bla". Third parties could add this call too.
>>
>> The only problem (and a big problem, at least I don't see a simple 
>> solution, but maybe someone else does) is how to refer to "the 
>> selector passed as the Nth parameter to beginSheet_bla_bla_bla".
>
> There's one problem with this: Selectors are basicly strings, you can 
> also use method references in Python but that is only sugar. The 
> method that you use to pass the selector to the object that will 
> perform the callback need not be the same as the method that you use 
> to pass the target. An example of this are the setTarget: and 
> setAction: methods of controls.

Theoretically you're right, but would that occur in practice (passing 
"obj1" as the target and "obj2.aMethod_" as the method)?
--
- 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: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

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

On woensdag, jun 11, 2003, at 21:34 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Wednesday, Jun 11, 2003, at 15:31 US/Eastern, Ronald Oussoren wrote:
>> We could warn about the signatures when one of the beginSheet methods 
>> is called (better yet, make it an error when the signature is not 
>> correct). How many of such callback API's are there, is it just 
>> sheets or are there other API's that do callbacks to aritrary methods 
>> with a 'difficult' signature?
>
> There aren't many, but that set may change over time... and, 
> certainly, third parties can (and have) modeled their class design 
> after Apple's.

All the potential problem cases would be where a selector is passed 
from Python to ObjC, right? Could we implement a mechanism (in the C 
code) where all selectors can optionally be checked for correct 
signature if a Python method is passed, and then expose a call to 
Python where you can turn this check on?

We then use this call to tell pyobjc "By the way, the selector passed 
as the Nth parameter to beginSheet_bla_bla_bla should have signature 
bla bla bla". Third parties could add this call too.

The only problem (and a big problem, at least I don't see a simple 
solution, but maybe someone else does) is how to refer to "the selector 
passed as the Nth parameter to beginSheet_bla_bla_bla".
--
- 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: FYI: Open Source Scripting Layer For Cocoa

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

On woensdag, jun 11, 2003, at 20:13 Europe/Amsterdam, bb...@ma... 
wrote:

> On Wednesday, Jun 11, 2003, at 06:50 US/Eastern, Michael Hudson wrote:
>> Well, if none of the online currency exchange rate sites let you
>> scrape the going rate, you could always fake one that returns a random
>> rate within some range and scrape that.  Not as good as the Real
>> Thing, but it might do.
>
> See the demo services at.....
>
>     http://xmethods.com/
>
> .... as any of them could easily be wrapped by a Cocoa/Python app.

Ah, brilliant! There's a currency converter in there.

Now the problem has been replaced by a new one: does anyone here know 
how to talk to a soap service from Python, and do we have all the 
necessary tools available in a standard Python installation?
--
- 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] FYI: we're broken on Fink

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

I've double-checked, and our archive builds just fine. They have a  
problem in their build procedures, or there is an incompatibility with  
one of the installed packages.

What's very strange is that they have a problem when building the  
objc.test.testbndl module, this is after the core objc._objc extension  
is build.

Ronald

On Thursday, Jun 12, 2003, at 06:33 Europe/Amsterdam, Bill Bumgarner  
wrote:

> https://sourceforge.net/tracker/ 
> index.php?func=detail&aid=751105&group_id=17203&atid=414256
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] FYI: we're broken on Fink

[Bill B. <bb...@co...>]

https://sourceforge.net/tracker/ 
index.php?func=detail&aid=751105&group_id=17203&atid=414256

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

[Bill B. <bb...@co...>]

On Wednesday, Jun 11, 2003, at 15:31 US/Eastern, Ronald Oussoren wrote:
> We could warn about the signatures when one of the beginSheet methods 
> is called (better yet, make it an error when the signature is not 
> correct). How many of such callback API's are there, is it just sheets 
> or are there other API's that do callbacks to aritrary methods with a 
> 'difficult' signature?

There aren't many, but that set may change over time... and, certainly, 
third parties can (and have) modeled their class design after Apple's.

b.bum

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

[Bill B. <bb...@co...>]

On Wednesday, Jun 11, 2003, at 15:27 US/Eastern, Ronald Oussoren wrote:
> I'm not comfortable about adding such limitations without much more 
> Cocoa experience than I have now.  	
> BTW. This wouldn't really limit the developer, the current method is 
> still there, but even so I think we should only add an informal 
> protocol if we're very sure that having one sheet per modalDelegate is 
> the right way to build Cocoa applications.

It isn't a safe assumption.   When building Cocoa apps, there are a 
number of reasonable situations in which a document controller -- a 
modal delegate -- may want to be able to deal w/multiple sheet 
open/close type notifications for different kinds of sheets.  
Obviously, not at the same time, but it is useful to have:

- (void)savePanelDidEnd:(NSWindow *)sheet returnCode:(int)returnCode 
contextInfo:(void *)contextInfo;
- (void)openPanelDidEnd:(NSOpenPanel *)sheet returnCode:(int)returnCode 
contextInfo:(void *)contextInfo;
- (void)printPanelDidEnd:(NSPrintPanel *)printPanel 
returnCode:(int)returnCode contextInfo:(void *)contextInfo;

And, if a developer is building an app w/a wizard or with other modal 
style presentation, they may have a slew of their own custom 
sheetDidEnd: methods, as well.

b.bum

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

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

On Wednesday, Jun 11, 2003, at 20:50 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Wednesday, Jun 11, 2003, at 14:10 US/Eastern, Ronald Oussoren wrote:
>> I'm afraid I don't see a way to automaticly detect that a method will 
>> be used as the callback for a sheet.
>
> Right.  I don't believe there is a great answer for this one-- at 
> least without asking developers to "follow a convention".
>
> In the case of that method, the method name doesn't matter.  It is 
> only the signature that matters-- even in ObjC.  You specify a name 
> and a method to be invoked, and it assumes the signature will be 
> compatible.
>
> But what if we wrapped the various methods that take signatures and 
> dynamically created and/or checked and/or enforced the signature at 
> that time?

We could warn about the signatures when one of the beginSheet methods 
is called (better yet, make it an error when the signature is not 
correct). How many of such callback API's are there, is it just sheets 
or are there other API's that do callbacks to aritrary methods with a 
'difficult' signature?

Ronald

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

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

On Wednesday, Jun 11, 2003, at 20:46 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>>
>> I'm afraid I don't see a way to automaticly detect that a method will
>> be used as the callback for a sheet.
>
> We could create an informal protocol, and use a naming convention for
> the method.

I don't like restricting the developer like that. That would limit the 
users to 1 sheet per modalDelegate, I'm not comfortable about adding 
such limitations without much more Cocoa experience than I have now.

BTW. This wouldn't really limit the developer, the current method is 
still there, but even so I think we should only add an informal 
protocol if we're very sure that having one sheet per modalDelegate is 
the right way to build Cocoa applications.

Ronald

Re: Naming question (was: [Pyobjc-dev] Cocoa Sheets)

[Bill B. <bb...@co...>]

On Wednesday, Jun 11, 2003, at 14:10 US/Eastern, Ronald Oussoren wrote:
> I'm afraid I don't see a way to automaticly detect that a method will 
> be used as the callback for a sheet.

Right.  I don't believe there is a great answer for this one-- at least 
without asking developers to "follow a convention".

In the case of that method, the method name doesn't matter.  It is only 
the signature that matters-- even in ObjC.  You specify a name and a 
method to be invoked, and it assumes the signature will be compatible.

But what if we wrapped the various methods that take signatures and 
dynamically created and/or checked and/or enforced the signature at 
that time?

There aren't that many entry points in the appkit that exhibit such 
behavior and every single one of them is precedent to a fairly 
laborious task-- popping down a sheet, for example-- and a few 
milliseconds spent validating API the first time through will never be 
apparent to the user (or developer).

?

b.bum