Thread: [Pyobjc-dev] Project Templates
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Bill B. <bb...@co...> - 2002-10-12 19:25:10
|
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
|
|
From: Bill B. <bb...@co...> - 2003-01-11 16:44:23
|
I have added a bunch of [ReST] documentation to the 00README.txt in Project Templates. If any of you has a chance, have a read and let me know if there are major holes. I really don't want to create a project template for every possible permutation -- some projects can provide examples for how to set up features of others. I have framework python installed on my machine and am going to do the embedded project templates against that -- it is much more likely that anyone with an embeddable command line version of Python will know how to modify the framework project to embed their command line interpreter. b.bum |
|
From: Ronald O. <ous...@ci...> - 2003-01-11 21:47:49
|
On Saturday, Jan 11, 2003, at 17:42 Europe/Amsterdam, Bill Bumgarner wrote: > I have added a bunch of [ReST] documentation to the 00README.txt in > Project Templates. If any of you has a chance, have a read and let > me know if there are major holes. I really don't want to create a > project template for every possible permutation -- some projects can > provide examples for how to set up features of others. > > I have framework python installed on my machine and am going to do the > embedded project templates against that -- it is much more likely that > anyone with an embeddable command line version of Python will know how > to modify the framework project to embed their command line > interpreter. It seems complete enough. The only project-type not on your list that I'd like to add some day is a project for python based plugins for Cocoa programs (like prefpanes). But we should add full thread-safety before doing that. Ronald |
|
From: Bill B. <bb...@co...> - 2003-01-12 00:52:37
|
On Saturday, Jan 11, 2003, at 16:46 US/Eastern, Ronald Oussoren wrote: > It seems complete enough. The only project-type not on your list that > I'd like to add some day is a project for python based plugins for > Cocoa programs (like prefpanes). But we should add full thread-safety > before doing that. One of my next projects will be a PB plugin [or something like it] -- more on that later. Out of that, a template may fall. I have just committed a new project template -- Cocoa-Python-ObjC Application. It is compatible with Apple's build of python and allows one to freely mix Objective-C and Python in the project. The ObjC all goes in an embedded framework. The Python can go anywhere. I also added a bunch of documentation to a 00README.txt file in Cocoa-Python Application -- I'll be adding the 'Classes & NIB' section next. That document really ought to be moved to somewhere else as it isn't totally specific to that template. b.bum |
|
From: Dinu G. <gh...@da...> - 2003-01-12 14:11:19
|
Bill Bumgarner: > I have added a bunch of [ReST] documentation to the 00README.txt in > Project Templates. If any of you has a chance, have a read and let > me know if there are major holes. I really don't want to create a > project template for every possible permutation -- some projects can > provide examples for how to set up features of others. Sounds good to me! Just a minor question: "Document-based app." means there there will be something like MyDocumentController.py and MyDoc\ ument.nib files available and prelinked to parts of the menu and available as object instances in MainMenu.nib, isn't it? Also, it should be stated somewhere what's needed to change the names of these "standard" filenames, including MyAppDelegate.py, especially, if the __main__.py needs to be changed... Thanks, Dinu -- Dinu C. Gherman ...................................................................... "Who controls the past, controls the future: who controls the present controls the past." (George Orwell, 1984) |
|
From: Bill B. <bb...@co...> - 2003-01-12 16:14:53
|
On Sunday, Jan 12, 2003, at 09:12 US/Eastern, Dinu Gherman wrote: > Bill Bumgarner: > >> I have added a bunch of [ReST] documentation to the 00README.txt in >> Project Templates. If any of you has a chance, have a read and let >> me know if there are major holes. I really don't want to create a >> project template for every possible permutation -- some projects can >> provide examples for how to set up features of others. > Sounds good to me! Just a minor question: "Document-based app." means > there there will be something like MyDocumentController.py and MyDoc\ > ument.nib files available and prelinked to parts of the menu and > available as object instances in MainMenu.nib, isn't it? Correct. The templates are designed to be exactly like their pure ObjC counterparts save for that the implementation is in Python. Because it is in Python, I also made sure each example builds an application that at least does some minimal target/action as an example of how to do such tasks in PyObjC. > Also, it should be stated somewhere what's needed to change the names > of these "standard" filenames, including MyAppDelegate.py, especially, > if the __main__.py needs to be changed... See 00README.txt in the Cocoa-Python Application project template. Good enough? b.bum |
|
From: Dinu G. <gh...@da...> - 2003-01-12 17:19:55
|
Bill Bumgarner: > Dinu Gherman wrote: >> Also, it should be stated somewhere what's needed to change the names >> of these "standard" filenames, including MyAppDelegate.py, especially, >> if the __main__.py needs to be changed... > > See 00README.txt in the Cocoa-Python Application project template. > Good enough? Well, I'm trying to follow what is mandates for running an install build on a different (10.1) box with Python in /usr/local/bin. So far I tried skipping some of the environment variables, but with no luck. In any case, I think I can't assume a non-Python user to go through the list in order to run any pyobjc app. Could they maybe bootstrap themselves using a shell script that de- termines the location of the current Python interpreter and does the rest magically before kicking off the app itself? Dinu -- Dinu C. Gherman ...................................................................... "CNN is one of the participants in the war. I have a fantasy where Ted Turner is elected president but refuses because he doesn't want to give up power. (Arthur C. Clarke) |
|
From: Bill B. <bb...@co...> - 2003-01-13 16:28:10
|
On Sunday, Jan 12, 2003, at 12:20 US/Eastern, Dinu Gherman wrote: > Well, I'm trying to follow what is mandates for running an install > build on a different (10.1) box with Python in /usr/local/bin. So > far I tried skipping some of the environment variables, but with no > luck. In any case, I think I can't assume a non-Python user to go > through the list in order to run any pyobjc app. OS X 10.1 doesn't ship with Python, so the user will have to have installed some kind of a Python distribution (or the app will need to ship with Python in the app wrapper). In either case, such a distribution will very likely be 'embeddable'. That is, will have a library, framework or dynamic-lib such that the interpreter can be embedded directly and the app won't have to hunt down the python distribution to be used. As such, you would probably want to use the 'Cocoa-Python Application (Embedded Interpreter)' template, which doesn't yet exist (but will soon, depending on the answer to the question I posed earlier today). PyObjC doesn't currently support OS X 10.1 anyway. It would not be hard to add -- easier now that GNUstep support has caused the 'build this version vs. that version' question to be answered with a concrete implementation. Because one of PyObjC's requirements is to support the build of Python that Apple ships with OS X, the default is to go after the python binary and do the execve() garbage. The assumption is also made that a python binary exists in /usr/bin/python and that most developers/users will never need to change it. > Could they maybe bootstrap themselves using a shell script that de- > termines the location of the current Python interpreter and does > the rest magically before kicking off the app itself? Yes. The bin-python-main.m could do exactly that. It is simply a matter of invoking `env python` via popen(), I believe. Of course, that will not pick up a python executable that only appears in the user's path in a Terminal environment. If that fails, a very simple binary could be provided that pops an Open Panel and asks the user to identify their python binary. Would not be hard to write, could be standardized and could be an added copy phase on the existing app projects (or a single source file).... b.bum |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X