Slashdot Mirror
Write Pure Python Cocoa Apps
bbum writes "Today, Ronald Oussoren and I patched the PyObjC (PythonObj-C) bridge to allow for completely standalone Cocoa applications that are implemented in Python. My 11-Oct-2002 weblog entries provide more detail and includes a link to a PyObjC Cocoa app that can be downloaded and hacked upon (with the app, you can actually create other apps without using the dev tools at all!). As the days pass, I'll be updating the 'blog with new software, updates, etc. A Fink package will be submitted shortly. (In reality -- Ronald did the hard stuff in that he figured out how to subclass ObjC classes in Python!!)" Nifty. Note there is also a PerlObjCBridge module included with Jaguar, and there's also CamelBones for Perl-Cocoa; what other scripting frameworks for Mac OS X are out there?
...is sombody going to let me do this with Forth?
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Sorry, I'm not very up on my Mac development...Does this mean TK apps will magically be sourcelevel cocoa-fied?
... why couldn't you write apps in Python before?
What on earth is the point of a programming language that you can't write apps in???
There are lots of these "WoW! Now you can use Programming Language X to do Y", but isn't the whole point of programming languages that you can do anything you want with them?
You will be able to write apps in Python (or Perl) and be able to use the Cocoa framework to make stand-alone apps.
This is different than porting the Tk GUI to Aqua. I know this also is being done for Python.
I would eventually like both.
My father is a blogger.
Sheesh, for a minute I thought you were kidding, but I guess not.
:-)
Yes, many languages are very powerful and allow you to do many things, but just because a language exists doesn't mean it magically includes support for everything -- including things that didn't exist at the time the language was created.
Generally, a language has a core set functionality that only provides a framework to build applications. Most languages then have a standard set of libraries implementing common functionality, and extended libraries implementing features outside the spec of the core and common APIs.
Anyway, Cocoa isn't written in Python, so you can't just use it from Python without an interface into the Cocoa framework. So, someone has provided an interface to Cocoa. Its not that Python was semantically unable to work with Cocoa, but that the mechanism didn't exist.
You should try something other than Visual Basic, maybe you'd learn about how software really works.
Don't blame me, I get all my opinions from my Ouija board.
PySoulseek must be made to run this way.
From reading the threads, let me respond with a bit of clarification.
This is really only of interest to Python programmers that want to leverage Cocoa or ObjC [including Cocoa] programmers that want to leverage the power of Python.
It is not intended to be used as a cross platform solution.
In context, it happens to be extremely powerful. The ability to subclass and extend ObjC classes with Python means that one can build Cocoa applications that can have their classes reloaded and redefined on the fly. I.e. it can greatly reduce the "run-compile" part of the "run-compile-edit" loop that developers tend to be stuck in.
Furthermore, having access to the power of Python from Cocoa greatly reduces the # of lines of code necessary to perform certain tasks. The Python libraries provide great, easy to use, HTTP client/server solutions, excellent XML-RPC support and a slew of other features that are damned handy to have around.
The real value of the PyObjC module-- and credit largely goes to Ronald for this-- is the transparency with which one can interact between languages. This isn't just a messaging solution (like CamelBones). PyObjC provides the developer with the ability to subclass ObjC classes from Python and-- if one really wanted to go there-- subclass Python subclasses of ObjC classes in ObjC.
As well, PyObjC tends to be a bit more straightforward in terms of integration than AppleScript Studio.
Think of it this way: PyObjC allows the developer to quickly and easily prototype applications in a scripting language [Python] while not sacrificing any of the awesome power of Cocoa [and awesome it is!].
Actually, you can use that as an advantage. Often times employers will ask you to write a "prototype" and then when it's done, they fire you and hire some monkeys to do upgrades.
If you do prototyping in python and Cocoa, you can be sure that won't happen.
You could write apps in Python, but they wouldn't be able to access the Cocoa frameworks. Now Python can be used to create apps that can have native GUIs, use Cocoa classes and collections, use OS X Services, etc.
Programing languages CAN be used to do (almost) anything, but they're not all DESIGNED to to everything. If you really want to, you can create a complete GUI app with just assembly language. But it would be infinitely easier to use a higher-level language like Python, Objective C, Java, etc. FORTRAN was designed for mathematically intense code, while Perl was designed for extraction and reporting; you wouldn't want to write (for example) engineering simulation code in Perl, or Slashcode in FORTRAN.
-Ster
What other scripting frameworks for Mac OS X are out there? Well there is a very nice one here.
Wow.
>>Combine the following:
>>Unpopular language: phython
>>Unpopular API: Cocoa
>>Result: a going-nowhere application
Then add some selfish unprofessionalism:
>Actually, you can use that as an advantage. Often
>times employers will ask you to write a "prototype" and
>then when it's done, they fire you and hire some
>monkeys to do upgrades.
>If you do prototyping in python and Cocoa, you can be
>sure that won't happen.
And you get the most godawful excuse to use two of the best new technologies on the planet. Yikes, what a stinker rationale that is. I hate the whole job security attitude. It has loused more promising projects than I care to think about, and has killed many a promising engineers career with apathy and defensive posturing. Once you start thinking in terms of job security, kiss your career and your projects successes goodbye.
What ever happened to using technologies which work well or have the advantage of rapid prototyping? Python and Cocoa both have reputations for being high leverage and powerful without forgoing speed when needed. Isn't that good enough to warrant their use?
Please! Keep job security arguments away from language choice and design decisions.
In the context of the article, an Application is a program that runs, has a native GUI, and has an icon in the dock. This has previously not been possible to do with Python under Mac OS X, without 3rd party toolkits such as wxWindows/wxPython.
This is absolutely excellent news! I downloaded this the second I read the article, and I have been playing with it for a few hours now. It works almost flawlessly. The only thing that could really make this better is if Apple picked it up and integrated Python as a first class citizen along with Java and Objective-C in Interface Builder and Project Builder.
... you will see the interactive Python interpreter fire up within a second. Its an amazing little language =)
People may ask "what's the point?" Well, for starters, Python is absolutely fantastic for building things quickly, especially for complex object or data structures that would take much more time to implement in Objective-C or Java.
On top of this, Python is much better suited for Cocoa than Java! Apple implemented the Java-Cocoa bridge mostly for the sake of having Java be a "supported language." But, since Java is inflexible and strongly typed, it doesn't really fit into the Objective-C model that Cocoa relies on. Python on the other hand is perfectly suited for Cocoa. Python is weakly typed and can handle the dynamic runtime of Cocoa a lot better than a language like Java.
In addition to this, Python's runtime is much more compact than Javas, and manages to load much more quickly. Just fire up Terminal.app and type "python"
I am very excited about the potential of this Python/Cocoa implementation! In the first hour or so since I installed this, I was able to take an existing Python backend and add a quick Cocoa frontend, using nothing but the standard OS X Development Tools.
Kudos to the great people who developed this!
Apple laptops are effectively unusable for unix users.
I am a long-time Unix user. That means I need to have the Ctrl key to the left of the A key. This is a genuine need, not merely a want; it is based upon ergonomics. The Ctrl key is heavily used in unix, and it must be easily accessable. It cannot be off in the lower left corner of the keyboard where it is difficult to get at, and where it distorts the position of your left hand such that you can't easily type other keys while holding the Ctrl key down.
Apple desktop keyboards are now all USB. They are all OK. The CapsLock key can be re-mapped into a Ctrl key.
Unfortunately, even in this modern age, all Apple laptops have built-in ADB keyboards. The ADB keyboard is broken-by-design. It is, in general, not possible to remap the CapsLock key into a Ctrl key.
There are some exceptions, but they are horrible kludges. They are horrible kludges because the original design of the ADB keyboard was a horrible kludge. The correct solution would be for Apple to re-design their laptop motherboards to use built-in USB keyboards. This hasn't happened yet. If you run Linux, use Debian's solution. For Mac OS X users, uControl works. There are no solutions (that I know of) for either NetBSD or OpenBSD. Please note once again that the "solutions" above are in fact kludges, because of the original bad design of the ADB keyboard.
Apple is (currently) ignoring Unix users! This is not merely speculation on my part. In an on-going email exchange I am having with an Apple employee (whom I won't name) in their marketing department, the Apple marketing person directly stated to me that Apple was catering to their historic Mac customers, and is purposely ignoring the Unix market. He also claimed that Apple would soon start paying more attention to the Unix market. I won't hold my breath. Apple has been ignoring Unix users for more than 12 years. I expect that trend to continue. (Also note that my Apple contact indicated that Macs would never ship with a 3-button mouse, even though Apple intended to port almost all X-window software and deliver it either on a CD/DVD or installed directly on each Mac's hard drive. How Unix friendly is a 1-button mouse with X programs that often require 3 buttons?)
Apple has now lost two opportunities to sell me hardware. I really wanted an Apple laptop for their superior battery life, and for the PowerPC with Altivec CPU. (The Altivec is vastly superior to the x86 line for DSP.) Because I can't live with the broken-by-design built-in ADB keyboard in all Apple laptops, Sony and IBM sold me laptops instead. If Apple fixes this problem, they will sell me a PowerBook next year; if they don't, I'll still be running OpenBSD on x86 hardware, and wishing I could use a Mac.