Archive for the 'Cocoa' Category

A few weeks ago, the SWT folks came out to Apple to learn a bit about Cocoa & Leopard.

Very early in the week, they discovered the BridgeSupport generated XML metadata that describes almost all Objective-C and C APIs on the system (and is included with user installations of Leopard).

Using that, they whipped up a tool that automatically generates a set of Java classes that mirror the Objective-C classes, with all the necessary glue bits underneath.

End result? SWT apps are now Cocoa apps. The goal is to host Eclipse on top of this version of SWT and they already have some success on that front.

Very cool.

All of this work has been pushed back into the SWT repository and they have now put out a call for help from the community.

After that long winded post with little useful content….

A few days ago, I finally downloaded and gave TextMate a try. Don’t know what took me so long as I had heard good things about it. I suppose the thought of potentially paying $50 to replace what I could get “for free” with Emacs turned me off.

Wow. Now this is an editor I can use! I will still use SubEthaEdit for collaborative editing, but TextMate is now my editor of choice when not working with Xcode projects.

To sum it up: TextMate takes the philosophy of emacs — giving close to total control to the user for customizing the user experience of text editing — and wraps it up into a simple and sweet Cocoa user interface. Sure, emacs has about three decades of development on TextMate and it is reflected in the power of the modes, but — frankly — the modes aren’t terribly accessible and Emacs hasn’t done a great job of keeping up with modern technologies.

None of this is to say that TextMate has a totally intuitive UI. It doesn’t. There is a definite learning curve. But that is too be expected — text editing is all about hands-on-the-keyboard and that requires learning a boatload of shortcuts.

TextMate has excellent documentation. At least, I have had no problem answering any question I might have by a simple search in the docs.

And it is extensible. I have already started to capture some silly little bits o’ functionality into a bundle.

If you are a TextMate user, you can check out my tmbundle

cd ~/Library/Application\ Support/TextMate/Bundles
svn co http://svn.red-bean.com/bbum/trunk/hacques/TextMate/BBum.tmbundle/

I’m sure the collection will grow over time.

Text editing is a weird thing. Every developer — nay, every computer user (but not every solitaire player) — has their own “unique” perspective as to what makes for a good text editor. And, of course, everyone else is wrong.

For anyone that has been pushing ASCII for more than a decade, there is guaranteed to be some “glory editor of days gone by” that every editor today is compared against. Yet, somehow, nothing measures up. Never mind that the code or text one was writing a decade ago was completely different than it is today.

For me, I caught the emacs taint almost 20 years ago (sheesh!). And caught it I did! Within a few years, I had a 100K init file. A few years after that, and I had a multi-megabit “initialization environment” that could magically customize itself based on operating system and emacs derivative.

It was awesome. I could code Obj-C or Perl (yeah, I did Perl for a while, too) like a daemon. Everything was beautifully formatted, builds happened in Emacs, yadda yadda yadda….

And then Project Builder was born out of the original Interface Builder (PB was a tab in the main IB document window) and it became the way to build NeXTSTEP apps. Same goes for WebObjects. Fortunately, there were some fellow emacs infected folk on the AppKit team and NSText (NXText) gained key bindings that gave the basics of text navigation and manipulation through a set of emacsen key bindings. (There was also Edit. It kicked butt.)

And time marched on…

Read the rest of this entry »

I demoed the latest build of PyObjC at the recent CocoaHeads meeting in Cupertino.

The demo concluded with a “show all [most, really] the tricks at once” sequence.

• How py2app, a part of PyObjC, will automatically create an installer package from a standard Python package
• Injecting a live Python interpreter into a running application
• Introspecting the application
• Interacting with Core Data, including dealing with ** style parameters
• Modifying a managed object and having KVO automatically fire on assignment

First, grab the top-of-tree source from the pyobjc repository:

svn co http://svn.red-bean.com/pyobjc/trunk/pyobjc/

Alternatively, you can mount that URL in the finder (click cancel on all the bloody attempts to write .DS_Store files) and cp -r the source to somewhere from the Terminal.

Then:

cd pyobjc
python setup.py bdist_mpkg --open

That will build PyObjC and open an Installer package that contains the runtime, documentation, examples, and Xcode templates.

Next, grab the OutlineEdit examples from /Developer/Examples/CoreData/ and run it.

Now, from the PyObjC source directory:
Read the rest of this entry »

I will be speaking at the CocoaHeads meeting on Thursday evening at the Apple campus. In particular, I’ll be focusing on PyObjC, including integration with various Tiger specific technologies, some history, and a focus on live demonstrations of the technology.

It will be rather freeform in nature. If anyone has any particular area of interest related to Python, Cocoa, and PyObjC, let me know.

So, after slogging long and hard through the wee hours of the night, ReSTedit now supports non-contiguous selection and columnar selection. Simply cmd-drag to extend the selection in a non-contiguous manner and option-drag to make a columnar selection.

It was really really hard to do.

Yup. That is all a pack of lies outside of that ReSTedit now has said features. I didn’t do anything other than notice a new feature in Cocoa’s Text subsystem. All Cocoa apps now support these features which means, of course, that all PyObjC apps support these features, as well.

Big Nerd Ranch was kind enough to send me a copy of their new book Core Mac OS X and Unix Programming in gratitude for editing the original Cocoa Programming for Mac OS X book.

The book is effectively the course materials for the Big Nerd Ranch course of the same name.

Co-authored by Mark Dalrymple and Aaron Hillegass, the book covers many advanced topics in the same clear/concise manner as Aaron’s original Cocoa programming book.

The book is focused on relatively advanced topics such as memory management, the run loop, multiple processes, rendezvous and many other topics. Instead of focusing on the high level details, each topic is investigated from the perspective of documenting the technical details– often non-obvious– through the use of examples, diagrams and discussions.

Two bits that immediately grabbed my attention–and are examples of the approach found in the rest of the book– where the discussion of malloc() behavior and the discussion of the run loop.

In the case of malloc(), the book precisely discusses the fact that malloc() does not necessarily return the number of bytes that you think it does — it often returns more based on certain internal optimizations. The end result is that quite a number of memory size reduction related optimizations are a complete waste of time! Instead, you might be able to consume a few extra bytes by not compressing the data structures and gain raw performance in terms of the # of CPU cycles needed to access the data.

The discussion of the run loop was also of great interest. It clearly diagrams the run loop and the exact point during the run loop — both CFRunLoop and NSRunLoop — that the various events and timers will be handled.

Excellent, excellent stuff.

The $100 price tag is a bit higher than most developer books, but the content is of an advanced and highly refined nature. $100 is a heck of a lot cheaper than $3,500 — the entrance fee to the class for which the book was written.

Big Nerd Ranch has also made a set of resources and forums available online.

Currently, most of my day is spent in OpenStep 4.2 working on porting a Very Large Body of Code from NeXTSTEP 3.3 to OS X / Cocoa. My current task is converting the NIB files from NS to OS as OS X can open OpenStep NIBs, but not NeXTSTEP NIBs. To complicate matters, the apps to be ported made relatively heavy use of InterfaceBuilder Palettes that are not going to be ported (obsoleted by new API). So, the port from NS->OS of the NIBs is actually not just a straight conversion as I’m also converting objects on the fly from one object model to another.
Very interesting stuff, really.

As we no longer have any Intel hardware that can run OpenStep, I’m running OS 4.2 under VPC for windows. It is faster than the native OpenStep-on-Until box I used 5 years ago. By jumping to full screen mode, you can’t even tell that Windows is the host OS!

Furthermore, it is possible– even easy– to configure VPC to allow the OpenStep box to have its own separate IP address. Once done, configuring OpenStep is exactly the same process it has always been (i.e. easy).

So, I’m no logged into an OS 4.2 box running under VPC that is mounting my home account, has all of the environment variables and defaults, etc.

Works flawlessly. Quite the retro-computing experience!