pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[<bb...@ma...>]

(Jack;  thanks for the CC to pyobjc.  I have now subscribed to 
pythonmac and will try to keep up with things in this SIG.)

First, a brief update on the progress made on the PyObjC project.

The module itself is now compatible with the Apple supplied build of 
Python 2.2.

At this point, the developer can create a new project in Project 
Builder, select "Cocoa-Python Application" (a custom template included 
with PyObjC), and Project Builder will create a new Cocoa application 
project that is implemented entirely in Python.  The project template 
includes an implementation for a basic application delegate (NSObject 
subclass) that includes target/actions, outlets, and notification 
handling.

When the 'install' target is used, the resulting application runs 
completely standalone on any OS X 10.2 machine without requiring that 
the user has preinstalled PyObjC or a custom build of Python.

In comparison to Cocoa-Java, the PyObjC bridge is significantly less 
intrusive.   More on this below.

In comparison to Cocoa-AppleScript (AppleScript Studio), the PyObjC 
bridge presents a development experience that is much closer to pure 
Cocoa.  AppleScript Studio is really a mix of Cocoa widgets into 
AppleScript style event handling-- the end result is very powerful, but 
it isn't Cooca programming.

At this point, the PyObjC bridge is being used in several production 
quality projects/products.  I.e. it is working now and working 
extremely well!!

(And, again, a huge note of thanks to Ronald -- his work on the 
subclassing and method dispatch mechanisms made it all possible.)

More information interspersed with Jack's and Ronald's text below.

On Wednesday, October 16, 2002, at 09:17 AM, Jack Jansen wrote:
> [I've added pyobjc-dev to the distribution]
> On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote:
>>> Something that is open to discussion, I think, is how to map ObjC 
>>> names to Python names. The current PyObjC code supports two 
>>> compile-time options, object.message_withFoo_(arg1, arg2) and 
>>> another that I forget with even more underscores in there (this 
>>> mapping is ambiguous: it maps to both [object message: withFoo:] and 
>>> to [object message_withFoo:]). The Java-ObjC brigde has simply 
>>> defined sensible static mappings for all names used in Cocoa, and 
>>> the above would probably become something like 
>>> object.messagewithFoo() or object.messageWithFoo(). Python's current 
>>> method is more flexible, but boy does it lead to ugly method names 
>>> in your code...
>>
>> Changing the mapping from Objective-C names to/from Python names is 
>> definitely open for discusion.
>>
>> BTW. The current PyObjC no longer supports object.message__withFoo__.

We have been down this path a number of times over the six year history 
of the PyObjC module.  In all cases, we have ended up back with the 
naming conventions that we have now for a number of reasons.   Moving 
from double underbar to single underbar was definitely a win -- made 
the code easier to read and write.

> I think that what I would like is one static scheme that is the same 
> (or almost the same) as the Java/ObjC naming scheme, plus a fallback 
> scheme (which could be the current message_withFoo_ scheme). There may 
> be a problem here with overloading, though: if I look at AppKitJava 
> there's often multiple ObjC selectors that map to one Java method 
> name, I'm not sure how they handle this, especially in the face of 
> overriding ObjC methods from Java.

The key value in the PyObjC module is that it provides an ObjC 
development experience that is about as close to transparent as can be 
achieved when mapping from one language to another.   One of the most 
frustrating aspects of doing ObjC/Java (the bridge existed back to 
WebObjects 3.0 in 1997) was because of the mapping of method names.  
Specifically, the developer effectively had to learn three APIs deeply 
to be effective -- the ObjC API, the Java SDK APIs, and this weird 
permutation of the ObjC APIs as presented in Java.

End result;  the developer is constantly frustrated by constantly 
having to do the mapping in their heads.  Worse, the mapped 
representation -- the conversion from, say, setObject:forKey: to 
setObjectForKey() -- loses the emphasis on the number and order of 
parameters that is emphasized by ObjC's method naming scheme.

 From personal experience-- both as a developer and a WebObjects 
training instructor-- I can confidently say that all of the effort that 
was put into presenting the ObjC API in Java such that it appeared to 
be a Java API caused a hell of a lot more confusion than it ever 
perpetuated clarity!

Even if it slightly less Python-Pretty, this...

     mutableDictionary.setObject_forKey_ ( "foo", "bar" )

... is ultimately easier to read and maintain than this...

     mutableDictionary.setObjectForKey( "foo", "bar" )

... for a number of reasons:

     - the first is immediately recognizable as an ObjC method call.  
Regardless of how transparent the bridge is, the bridge is there and it 
does affect behavior.  Trying to hide it makes maintenance 
significantly more expensive and the introduction of new developers 
into a project harder.  (I helped maintain a mixed ObjC<->Java codebase 
with 500,000+ lines of code for over 3 years.   The bridge was the 
single largest cause of problems in the project -- that it tried to 
hide the "crossing of the bridge" just confused things.)

     - the first form preserves the argumentation information as 
provided by the traditional ObjC method name (setObject:forKey:)-- the 
developer can easily map between that syntax and the original ObjC 
method.  The second loses that information and the developer can easily 
assume that the key should be first.   This is a huge problem among my 
development team with WebObjects 5.x -- all of us make this kind of 
mistake on a regular basis.

     - the first has the distinct advantage of allowing the developer to 
*always* be able to deduce the original ObjC method name by simply 
looking at the code.  The developer doesn't have to go follow some 
random mapping to try and figure out what the ObjC method's name 
originally was.

> Hmm, even if that isn't possible we could cop out: if the method name 
> translation routine finds that a certain name isn't in the 
> dictionaries it would simply add it. Or (more cumbersome, but safer) 
> there could be a (Python) API MapObjCSelector('message:withFoo', 
> 'messageWithFoo') which could then also check that this mapping 
> doesn't conflict with another one. With such a scheme the Python 
> programmer would have to declare any new ObjC messages it uses, but 
> the question is how often this will happen.

Anything that adds more steps to the bridging process is bad.  One of 
the most powerful and valuable aspects of the PyObjC bridge is that it 
so totally transparent;  much more so than CamlBones (doesn't do 
subclassing), Java<->ObJC (changes the API) and AppleScript<->ObjC (not 
intended to be transparent at all).

The developer is going to be defining new ObjC methods quite often.  
The current PyObjC module can complete replace ObjC within a Cocoa 
project.  That is, Python is used to create all of the custom classes 
that one would normally find in a Cocoa project.   As such, the 
developer is writing lots of custom methods that implement the 
functionality specific to their application.   Certainly, there are 
many cases where the developer is simply overriding existing Cocoa 
providing functionality.

As it is, many of those methods have to be declared such that the 
bridge can figure out how to do the dispatch.   Very unfortunate, in 
and of itself, but livable.   It would be even more unfortunate if 
every single action method and other custom methods had to be declared, 
as well!

b.bum

Re: [Pyobjc-dev] exception handling design pattern

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

On Wednesday, October 16, 2002, at 02:42 AM, Ronald Oussoren wrote:
> On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> Looking at the implementation, it looks like the problem lies in the 
>> behavior of the ObjC->Python part of the bridge in that it leaves the 
>> NSException in a wrapped up state?
> That's right. I never got around to implement this, adding this code 
> should be relatively straightforward. I'll look into it.

Thanks.   It isn't a huge issue, but anything that makes the bridge 
more transparent is definitely a boon.

BTW:  The bridge is working *really* well.  I'm using it in a 
production development setting and have had 0 problems other than of my 
own making (the exception issue wasn't a big deal).

> BTW. I've been playing with libffi and I'm pretty sure it can be used 
> to remove the need for the register.m file. I already have a function 
> that returns an 'IMP' for in the Objective-C method dispatch table 
> (given a method signature). I can't test this at the moment because 
> libffi refused to build into a shared library...

If the inclusion of a shared library requires end users of standalone 
applications to go through some kind of installation process to have 
the shlib dumped off in the proper location, I will be very strongly 
against the inclusion of features that require a shared library.

The value of the PyObjC bridge is primarily that it can be used so 
transparently within the X environment.    At this point, the PyObJC is 
considerably more straightforward to use than the Java-ObjC bridge and 
is easier to use than the AppleScript Studio bridge.

Anything that takes away from that transparency must have a huge return 
on investment to be worth it.

With all that said, eliminating the register.m based dispatch would 
certainly be a win.   Did you receive my earlier message regarding 
method dispatch within the Java<->ObjC bridge?   It was able to do its 
thing without requiring a mapping for every method and without 
something like the register.m functionality.

I really need to dig more deeply into this particular problem.

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Wednesday, October 16, 2002, at 04:49 , Ronald Oussoren wrote:

> To reply to myself...
>
> Another mapping scheme would be to just drop the colons and translate 
> the character just beyond colons to uppercase. This would make the 
> python methodnames more pleasant, although still long and 'foreign 
> looking':
>
> 	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)

I think the bottom line is: which method makes it easiest to write 
Python code given Apple's documentation? I must say I haven't looked at 
the Java Cocoa documentation (actually, I tend to read the ObjC header 
files mostly) but if that is good then I think we should stick with the 
Java names. If it isn't good (or nonexistent:-) then an algorithmic name 
translation scheme is probably best.

Something else that might be worthwhile is a helper command that 
translates ObjC calls to Python. You would then copy [obj setObject: 
value forKey: key], paste it in your Python script (where it will stay 
selected) and select the "ObjC methodcall to Python" command to turn it 
into obj.setObjectForKey(value, key). The only question is how we could 
get this into Project Builder (into the Python IDE would be easy).
--
- 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: [Pythonmac-SIG] pyobjc / cocoa

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

To reply to myself...

Another mapping scheme would be to just drop the colons and translate 
the character just beyond colons to uppercase. This would make the 
python methodnames more pleasant, although still long and 'foreign 
looking':

	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)

Ronald

[Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Wednesday, Oct 16, 2002, at 15:17 Europe/Amsterdam, Jack Jansen 
wrote:
>
> I think that what I would like is one static scheme that is the same 
> (or almost the same) as the Java/ObjC naming scheme, plus a fallback 
> scheme (which could be the current message_withFoo_ scheme). There may 
> be a problem here with overloading, though: if I look at AppKitJava 
> there's often multiple ObjC selectors that map to one Java method 
> name, I'm not sure how they handle this, especially in the face of 
> overriding ObjC methods from Java.

I agree that using the naming scheme as from the Java-Cocoa bridge 
would be usefull. Making up yet another naming scheme would be IMHO be 
unwise, if only because this would make it very hard to find 
documentation.

W.R.T. mapping multiple selectors onto the same java method in the Java 
bridge: I suppose these are selectors that are logically 1 method with 
a number of default arguments, and the ones with less arguments 
probably call the ones with more arguments:
	[object foo]	-> [object fooWithArg:nil andNum:nil]
	[object fooWithArg:arg] -> [object fooWithArg:arg andNum:nil]
	[object fooWithArg:arg andNum:arg2]

>
> The static scheme could simply be a Python dictionary (or an 
> NSDictionary, but a Python dictionary is easier to initialize, I 
> guess) that we initialize with Python code, where the Python code is 
> generated by running /Developer/Java/Jobs/*.jobs through a script. 
> Fastest is probably to create both Python->ObjC and ObjC->Python 
> dictionaries.

I was thinking along the same lines. The actual datastructure should be 
hidden,
you'd just call a global function in the objc module to map an 
Objective-C selector on a Python method name.

>
> Is it still possible to have two name mapping schemes, where first one 
> is tried and then the other? Or would this wreak havoc now that we 
> have two-way inheritance and such?

Having two mapping scheme's is not really a problem. That is, unless 
you want to be able to access a method using both mapping schemes at 
the same time.

The current code does something like the code below while creating a 
proxy class for and objective-C class:

def map_selector(sel):
	return sel.replace(':', '_')

def make_methods(ocClass, clsDict):
	for meth in ocClass.methods():
		clsDict[map_selector(meth.selector)] = wrapMethod(meth)

The proxy class is created once including all methods. There is some 
additional code that recalculates the class dict whenever the method 
list of the Objective-C class changes. This may happen when loading a 
bundle that defines additional categories for existing classes.

It would be fairly easy to replace the 'map_selector' function by a 
function that first does a lookup in a translation table.

IMHO it is highly unlikely that users define completely new selectors 
in Python, other than new actions for use in Interface Builder, and I 
already have written a module that reads the classes.nib from a .NIB 
'file' and creates a python module containing the corresponding python 
classes. Using names without underscores for IBActions is therefore 
very easy.

Ronald

[Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

[I've added pyobjc-dev to the distribution]

On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote:
>> Something that is open to discussion, I think, is how to map ObjC 
>> names to Python names. The current PyObjC code supports two 
>> compile-time options, object.message_withFoo_(arg1, arg2) and another 
>> that I forget with even more underscores in there (this mapping is 
>> ambiguous: it maps to both [object message: withFoo:] and to [object 
>> message_withFoo:]). The Java-ObjC brigde has simply defined sensible 
>> static mappings for all names used in Cocoa, and the above would 
>> probably become something like object.messagewithFoo() or 
>> object.messageWithFoo(). Python's current method is more flexible, but 
>> boy does it lead to ugly method names in your code...
>
> Changing the mapping from Objective-C names to/from Python names is 
> definitely open for discusion.
>
> BTW. The current PyObjC no longer supports object.message__withFoo__.

I think that what I would like is one static scheme that is the same (or 
almost the same) as the Java/ObjC naming scheme, plus a fallback scheme 
(which could be the current message_withFoo_ scheme). There may be a 
problem here with overloading, though: if I look at AppKitJava there's 
often multiple ObjC selectors that map to one Java method name, I'm not 
sure how they handle this, especially in the face of overriding ObjC 
methods from Java.

The static scheme could simply be a Python dictionary (or an 
NSDictionary, but a Python dictionary is easier to initialize, I guess) 
that we initialize with Python code, where the Python code is generated 
by running /Developer/Java/Jobs/*.jobs through a script. Fastest is 
probably to create both Python->ObjC and ObjC->Python dictionaries.

Is it still possible to have two name mapping schemes, where first one 
is tried and then the other? Or would this wreak havoc now that we have 
two-way inheritance and such?

Hmm, even if that isn't possible we could cop out: if the method name 
translation routine finds that a certain name isn't in the dictionaries 
it would simply add it. Or (more cumbersome, but safer) there could be a 
(Python) API MapObjCSelector('message:withFoo', 'messageWithFoo') which 
could then also check that this mapping doesn't conflict with another 
one. With such a scheme the Python programmer would have to declare any 
new ObjC messages it uses, but the question is how often this will 
happen.
--
- 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] exception handling design pattern

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

On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner 
wrote:
> Looking at the implementation, it looks like the problem lies in the 
> behavior of the ObjC->Python part of the bridge in that it leaves the 
> NSException in a wrapped up state?

That's right. I never got around to implement this, adding this code 
should be relatively straightforward. I'll look into it.

BTW. I've been playing with libffi and I'm pretty sure it can be used 
to remove the need for the register.m file. I already have a function 
that returns an 'IMP' for in the Objective-C method dispatch table 
(given a method signature). I can't test this at the moment because 
libffi refused to build into a shared library...

Ronald

[Pyobjc-dev] exception handling design pattern

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

If I implement something like...

   def foo(self):
     try:
       serverAPIVersion = int( versionInfo['currentXmlRpcVersion'] )
       serverAppVersion = int( versionInfo['applicationVersion'] )
     except KeyError, aKey:
       NSException.raise_format_(NSInternalInconsistencyException, " ** 
%s key not found in getVersionInfo() response>" % aKey)

... and am calling this code from ObjC (i.e. objc->python->objc 
exception), I would expect that the raised NSException would be 
transparently passed back through to ObjC.  That is:

NS_DURING
     [instanceOfPythonObject foo];
NS_HANDLER
     ... handle the raised NSException here ...
NS_ENDHANDLER

This would seem to be consistent with the ObjC implementation pattern.  
That is, it wouldn't matter if -foo is implemented in Python or in the 
ObjC parent class of the python class, the behavior would be consistent.

Looking at the implementation, it looks like the problem lies in the 
behavior of the ObjC->Python part of the bridge in that it leaves the 
NSException in a wrapped up state?

I'm not sure how this would influence the relatively complex situation 
of, say, ObjC->Python->ObjC->Python->Objc exception raised... I.e. in 
the 'ObjC' parts of the stack, you want to raise the exception and let 
the next level up's interface between Python->ObjC catch it, convert it 
into the appropriate Python exception, then convert it back into an 
NSException at the next ObjC->Python extension (keeping in mind that 
the exception goes from right to left).

b.bum

Re: [Pyobjc-dev] Cocoa Pie

[<bb...@ma...>]

Jeez.  Can't win.  If I put raw dmgs on the site, OmniWeb displays the 
contents inline...

On Monday, October 14, 2002, at 06:12 PM, Frank Steele wrote:
> Works like a charm in IE; Chimera shows signs of not recognizing the 
> .gz
> extension.

Re: [Pyobjc-dev] Cocoa Pie

[Frank S. <fs...@mi...>]

Works like a charm in IE; Chimera shows signs of not recognizing the .gz
extension.

Thanks!

Frank

> 
> Try:
> 
>    http://pyobjc.sourceforge.net/software/
> 
> I mirrored everything from friday.com to that site.  Of course, I don't
> think the project pages are really supposed to be for downloads, but it
> isn't like we'll have a *huge* amount of traffic in comparisons to
> other projects.   It'll do for now -- off to figure out how to do the
> whole project file release thing....
> 
> b.bum
> 
> On Monday, October 14, 2002, at 05:09 PM, Frank Steele wrote:
> 
>> I'm excited about the ObjC-Python bridge, but I have as yet been
>> unable to
>> download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it
>> repeatedly times out.
> 

Re: [Pyobjc-dev] Cocoa Pie

[<bb...@ma...>]

Try:

     http://pyobjc.sourceforge.net/software/

I mirrored everything from friday.com to that site.  Of course, I don't 
think the project pages are really supposed to be for downloads, but it 
isn't like we'll have a *huge* amount of traffic in comparisons to 
other projects.   It'll do for now -- off to figure out how to do the 
whole project file release thing....

b.bum

On Monday, October 14, 2002, at 05:09 PM, Frank Steele wrote:

> I'm excited about the ObjC-Python bridge, but I have as yet been 
> unable to
> download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it
> repeatedly times out.

Re: [Pyobjc-dev] Cocoa Pie

[<bb...@ma...>]

I'm on it now....  CodeFab's T1 blew up this morning (should be up 
soon, soon, soon) and friday.com is behind that T1.

b.bum

On Monday, October 14, 2002, at 05:09 PM, Frank Steele wrote:

> I'm excited about the ObjC-Python bridge, but I have as yet been 
> unable to
> download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it
> repeatedly times out.
>
> Is there any way Bill or Ronald could post it to sourceforge? With all 
> the
> good press this has been getting, I'm sure a lot of people are 
> downloading
> it, and more folks will look for it at SF, which of course can support 
> a
> tremendous number of simultaneous downloads....
>
> Thanks for all the work -- this is why I signed onto the list months 
> ago!
>
> Frank

[Pyobjc-dev] Cocoa Pie

[Frank S. <fs...@mi...>]

I'm excited about the ObjC-Python bridge, but I have as yet been unable to
download it from www.friday.com/software/python/PyObjC 0.7.0.dmg -- it
repeatedly times out.

Is there any way Bill or Ronald could post it to sourceforge? With all the
good press this has been getting, I'm sure a lot of people are downloading
it, and more folks will look for it at SF, which of course can support a
tremendous number of simultaneous downloads....

Thanks for all the work -- this is why I signed onto the list months ago!

Frank

[Pyobjc-dev] Kudos from the community

[<bb...@ma...>]

Received this this morning -- nice way to start the day!

(I asked before posting this and Jonathon gave me permission to forward 
it along... he also indicated that he would like to see PyObjC ship 
w/OS X.   If enough folks file requests via bugreport.apple.com, it 
might just happen. :-)

b.bum

> On Monday, October 14, 2002, at 02:12 AM, Jonathan LaCour wrote:
>
>> Hello,
>>
>> I just installed your Python/Obj-C bridge and was able to take an 
>> existing Python back end and add a beautiful Cocoa UI within an hour 
>> of use.  The ease of development of Python and Cocoa together at >> 
>> last!
>>
>> Thank you, thank you, thank you!
>>
>> Greatfully,
>>
>> 	Jonathan LaCour
>> 	5th Year Senior, Computer Science at Georgia Tech
>> 	Currently Seeking Employment

[Pyobjc-dev] packaging

[<bb...@ma...>]

It only supports the old style packages -- not catastraphic, by any 
means, it'll just require a bit of work to make it generate a proper 
10.2 package.   The key advantage with 10.2 packages is that it allows 
the package to explicitly require that it be installed on the root 
volume only.

In general, the package should likely be an mpkg that contains:

     - a mandatory package containing the compiled module installed into 
/usr/lib/python2.2/site-packages

     - an optional package containing the Examples -- default 
installation into /Developer/Examples/Python/?

      -an optional package containing the Documentation (if any :-) -- 
/Developer/Documentation?

     - an optional package containing the PBX project template(s) -- 
/Developer/Project Builder Extras/....

b.bum

On Sunday, October 13, 2002, at 12:33 PM, Bill Bumgarner wrote:
[referencing the buildpkg.py script]
> Oh, cool.  Does it support the new style packages or only old?  I'll 
> have to check it out...


b.bum
Wake up. Breathe....
	.... keep breathing.

Re: [Pyobjc-dev] New version of package

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

Oh, cool.  Does it support the new style packages or only old?  I'll 
have to check it out...

b.bum

On Sunday, October 13, 2002, at 12:12 PM, Ronald Oussoren wrote:

> On Sunday, Oct 13, 2002, at 17:36 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> The whole package building process is currently manual.  It needs to 
>> be automated and become part of the build process.  That isn't 100% 
>> trivial, but at least Apple has now documented package structure a 
>> bit better.
> It might be easier than you think. There is a script for this in the 
> Python CVS repository (buildpkg.py by Dinu Gherman)

Re: [Pyobjc-dev] New version of package

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

On Sunday, Oct 13, 2002, at 17:36 Europe/Amsterdam, Bill Bumgarner 
wrote:
> The whole package building process is currently manual.  It needs to 
> be automated and become part of the build process.  That isn't 100% 
> trivial, but at least Apple has now documented package structure a bit 
> better.
It might be easier than you think. There is a script for this in the 
Python CVS repository (buildpkg.py by Dinu Gherman)

Ronald

[Pyobjc-dev] New version of package

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

I put a new version of the binary package on 
http://www.friday.com/software/python/

It contains the Readme and License text.   The Readme had to be edited 
to only use newlines at the end of the lines.

New package definition is in repository;   but it won't work for anyone 
but me, i bet, because of path references.

The command line 'package' tool provided by apple is totally and 
completely broken -- don't bother with it.

The whole package building process is currently manual.  It needs to be 
automated and become part of the build process.  That isn't 100% 
trivial, but at least Apple has now documented package structure a bit 
better.

b.bum

Re: [Pyobjc-dev] Packaging

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

On Sunday, October 13, 2002, at 04:01 AM, Ronald Oussoren wrote:
> This is pretty neat. I did find something to nag about: I'd prefer if 
> the installer showed in the README file.

That'd make sense -- I would also like to shove a/the license in 
(currently, the MIT license is in the repository -- it seems to be the 
easiest / most open license around and I couldn't find a concise and 
appropriate version of the python license in a module context).

Oh.  Duh.  There is a Package Format Notes menu that I *completely* 
ignored...   will fix.

>
> Are there any reasons left to postpone a new release? If not we could 
> publish this and a source archive on sourceforge.

None that I can think of.  This version seems to be pretty rock solid 
to the point of being able to support complex application development.  
  The examples could use some cleanup, but that will always be the case.

>
> BTW. The current CVS version will probably _not_ compile on 10.1, due 
> to the additional enum-labels in the AppKit package.

Oh -- I forgot about that.   I'll have to update the notes on my blog.

b.bum

[Pyobjc-dev] A million thanks

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

Yo,

Just a small note to say a huge THANK YOU to all of you guys and 
especially to bbum, Ronald, Jack for making it not only possible but 
even easy to develop Cocoa apps in Python.

I've been longing for being able to do this for so many years.

This is one of the coolest thing to happen since Mac OS X.

= tmk =

Re: [Pyobjc-dev] Packaging

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

This is pretty neat. I did find something to nag about: I'd prefer if 
the installer showed in the README file.

Are there any reasons left to postpone a new release? If not we could 
publish this and a source archive on sourceforge.

BTW. The current CVS version will probably _not_ compile on 10.1, due 
to the additional enum-labels in the AppKit package.

Ronald

On Saturday, Oct 12, 2002, at 23:01 Europe/Amsterdam, Bill Bumgarner 
wrote:

> I put together an installer package that includes the PyObjC module 
> and the Project Builder template.  See...
>
>     http://radio.weblogs.com/0100490/
>
> For more information.
>
> I also reorganized the README a bit to reflect the current state of 
> things.
>
> b.bum
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Packaging

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

I put together an installer package that includes the PyObjC module and 
the Project Builder template.  See...

     http://radio.weblogs.com/0100490/

For more information.

I also reorganized the README a bit to reflect the current state of 
things.

b.bum

[Pyobjc-dev] Project Templates

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

I took Jiva's suggestion and created a Project Templates directory 
within the pyobjc source tree.   It currently contains a single 
template;  Cocoa-Python Application.   It is an edited copy of the 
standard Cocoa Application template.

When used, the template creates a Cocoa project with the following 
features/attributes:

     - includes a Main.py that initializes the bridge appropriately

     - includes a copy files phase that copies the pyobjc module into 
the app wrapper on installation

     - includes a basic application delegate class implemented in Python 
(MyAppDelegate.py)

     - upon execution, the application presents a simple window with a 
button and a field.  Click the button and an action handler fills the 
field with data.

     - only links the Foundation framework, but includes AppKit and 
Cocoa for indexing purposes

Damned handy -- thanks Jiva!

Some notes on creating templates:

     - always remove the .pbxuser file from the pbproj directory

     - make sure and edit the list of files that need expansion in the 
TemplateInfo.plist file (found in the pbproj)

     - it is also possible to automatically rename files

b.bum

Re: [Pyobjc-dev] Project builder project template...

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

Excellent.  I'm reworking it a bit to provide a more complete example 
of how to set up a project "out of the box".  A basic "Hello World", if 
you will.   More like the multi-document Cocoa example (which that 
template will be the next to port over).

I'll commit something into CVS shortly....

I see that PyObjC made DayPop -- seems we have caused quite the stir in 
the technical 'blogging community.

http://www.daypop.com/top/

b.bum

On Saturday, October 12, 2002, at 01:24 AM, Jiva DeVoe wrote:

> I have taken your sample project and put it into a template suitable 
> for putting into the rest of the project builder templates in 
> /Developer/ProjectBuilder Extras
>
> You can download this template at:
>
> http://www.devoesquared.com/pyobjc_template.tar.gz
>
> Feel free to add this to cvs if you guys find it useful.

Re: [Pyobjc-dev] This is so cool!

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

On Saturday, Oct 12, 2002, at 00:56 Europe/Amsterdam, Jiva DeVoe wrote:

> So we can now rapidly prototype in python, and when we find 
> bottlenecks needing to be faster, we recode that code in Obj-C.  This 
> almost seems too good to be true! :)

That was my plan, so this better be true ;-) I'd like to avoid the 
'recode in Obj-C' part though.

Ronald