pyobjc-dev

[Pyobjc-dev] Best way...??

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

Hi,

In the tutorial.html file, the process of creating a PyObjC app without
Project Builder is described.

In the TableModel2 example, the readme.txt file describes how to use Project
Builder, starting with creating a new "Cocoa Application" in PB.

In Project Builder itself, there is a choice to create a Cocoa-Python
application under "New...". This seems to result in a substantially
different setup than the TableModel2 example does.

Is there any technique that is "safest" in terms of using well-tested code
out of the above three? Is there a worst technique?

I'd kind of like to use PB, but it's much more important to me to use
well-tested, highly maintained code.

--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] Best way...??

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

On maandag, mei 12, 2003, at 22:45 Europe/Amsterdam, Gary Robinson 
wrote:

> Hi,
>
> In the tutorial.html file, the process of creating a PyObjC app without
> Project Builder is described.
>
> In the TableModel2 example, the readme.txt file describes how to use 
> Project
> Builder, starting with creating a new "Cocoa Application" in PB.
>
> In Project Builder itself, there is a choice to create a Cocoa-Python
> application under "New...". This seems to result in a substantially
> different setup than the TableModel2 example does.
>
> Is there any technique that is "safest" in terms of using well-tested 
> code
> out of the above three? Is there a worst technique?
>
> I'd kind of like to use PB, but it's much more important to me to use
> well-tested, highly maintained code.

The choice of PB or non-PB development probably depends on two things:
1. What are you familiar with, and
2. Where is your application going to go.

If you come from an ObjC background PB is probably the best choice, if 
you come from a pure Python background non-PB is better. But if your 
app is eventually going to be rewritten in ObjC (completely or 
partially) then PB is best. And if you use PyObjC only as a quick GUI 
layer around a complex Python package that's going to be cross-platform 
(using another toolkit on non-Mac systems) then non-PB is best.

All that said, it might be a good idea to duplicate the tutorial and 
explain how to get the same end result using PB. I would be very 
interested in following that tutorial:-).

Any takers?
--
- 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] Best way...??

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

Thanks Jack!

This app is going to be a cross-platform Python app; we're using Cocoa for
the Mac interface, but will obviously use other tools for the UI for other
platforms. (I'm hoping GnuStep will work but we'll see...)

So it looks like the non-PB approach is best, based on your note below.

Thanks again!

--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] Best way...??

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

On Monday, May 19, 2003, at 09:09 US/Eastern, Gary Robinson wrote:
> This app is going to be a cross-platform Python app; we're using Cocoa 
> for
> the Mac interface, but will obviously use other tools for the UI for 
> other
> platforms. (I'm hoping GnuStep will work but we'll see...)
>
> So it looks like the non-PB approach is best, based on your note below.

Sorry -- I'm diving into this conversation late....

For cross platform work, I would suggest you package all the portable 
code using the standard distutils packaging tools (or something 
similar).

For the Cocoa app, PB or buildapp will both work.   PB has an advantage 
in that once the project is indexed, you have excellent integration 
with documentation for Cocoa directly into your project.  In 
particular, I find being able to cmd or opt double click a method to go 
to the declaration or documentation, respectively, to be a tremendous 
boost to productivity.

Also -- for the OS X solution, it is likely that you will eventually 
need to compile some code in for one reason or another.   Maybe 
performance, maybe ease of development, maybe need of accessing APIs 
that are not yet or not easily wrapped....

In that case, you will likely need to have a PBX project -- even if it 
is just a bundle project that is loaded by your pure Python code....

b.bum

Re: [Pyobjc-dev] Best way...??

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

bb...@ma... wrote:

> [ ... ] I find being able to cmd or opt double click a method to
> go to the declaration or documentation, respectively, to be a
> tremendous boost to productivity.

How does that work for Python code?

> Also -- for the OS X solution, it is likely that you will eventually
> need to compile some code in for one reason or another.   Maybe
> performance, maybe ease of development, maybe need of accessing APIs
> that are not yet or not easily wrapped....
> 
> In that case, you will likely need to have a PBX project -- even if
> it is just a bundle project that is loaded by your pure Python
> code....

OTOH, if it's a Python extension it's probably easiest to just write a
distutils script for it (also works for .m files!).

Just