About
Code by Kevin: Programming, code, business, and other pursuits
Your Host
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
2008
2007
2006
Categories
Business
Software
General
Fri, 08 Aug 2008
Phynchronicity 2.2
Today I've released version 2.2 of Phynchronicity, my GUI for the Fink Unix-software package management system on Mac OS X. This release adds several improvements, including a faster display of all Fink packages; Growl support; and various UI improvements to give the user greater control of application windows, product updates, and display of their serial number. It's a free upgrade for registered users. If you are a Fink user and are tired of using obsolete, unmaintained GUI tools for Fink, give Phynchronicity a try.
I want everyone to know that, despite my frequent ruminations about Apple essentially forcing developers to migrate to their privileged Cocoa frameworks, I haven't been neglecting my products. Today I released a new version of PortAuthority, and major and/or minor updates of all of my other products are also in the works.
For my products, updates tend to fall into two categories: application-specific improvements; and infrastructure improvements that can be added to each of my programs. This means that I often release updates in clusters, because they reflect improvements in frameworks and extensions that I use across my applications.
PortAuthority 2.6, my GUI for the MacPorts Unix software management system, is now out.
It's been seven months since the last release. PortAuthority is fairly mature and bug-free as a product, so there is less need to update it frequently. However, the new release contains some useful new features, including a faster display of all MacPorts packages; Growl support; and various UI improvements to give the user greater control of application windows, product updates, and display of their serial number.
2.6 is a free update to registered users. If you use PortAuthority, you'll want to install the new version.
Fri, 25 Jul 2008Jason Slack has posted a website that will document his efforts to port Tk to run on top of Cocoa, instead of Carbon.
To keep abreast of the project, visit http://softwareforeveryone.info, and click on "Projects/Tcl-Tk Work" or "blog."
Thanks, Jason! Your hard work on this project is much-appreciated.
Michiel van Meeteren did a research project for graduate school on the independent Mac development community, called "Indie Fever." The paper can be downloaded here.
It's an interesting overview of the community, and it has a lot of good points, but it has one serious flaw: it assumes that the Mac development community is comprised strictly of Cocoa developers. It even goes so far as to assert that independent Carbon development, for all intents and purposes, is dead.
Not true. I can think of several independent Mac developers, including Skytag Software, LemkeSoft, Black Cat Systems, and Fetch Softworks, who should be counted as vital members of the independent Mac development community. They develop with Carbon, or a Carbon wrapper such as RealBasic.
Why weren't these developers discussed at all in this paper? Why does the paper's author automatically equate Mac development with Cocoa development?
Barrier to development on Apple: getting higher or lower?
Many Cocoa developers applaud the increasing emphasis that Apple is placing on Cocoa as the main development framework for OS X. They also believe that Apple is making it easier than ever to learn Cocoa, by adding such features as "garbage collection" to the language (which reduces the amount of effort developers have to spend managing memory), and by directly supporting scripting bridges to Cocoa (specifically, PyObjC for Python developers and RubyCocoa for Ruby developers). The consensus about Apple's lowering the barrier to learning Cocoa is even shared by curmudgeonly Cocoa developers, who grumble that Apple is watering down standards, making it too easy to write Cocoa software, which will lead to lots of bad software.
I'm not sure I agree that Apple is lowering the barrier to entry on Mac development.
All the features that Apple is adding to Cocoa will make it somewhat easier to pick up developing with the Cocoa frameworks. However, the increasing emphasis on Cocoa means that it's now pretty much the only show in town for Mac development. And if you don't write in Cocoa, the migration path to Cocoa is not easy. Anyone doing development based on the Carbon frameworks--either directly or with a higher-level toolkit--has a higher, rather than lower, barrier to entry.
I've taken a step back from Aaron Hillegass' Cocoa programming book to learn the foundational language of Cocoa: C.
Yes, I know the actual core language of Cocoa is Objective-C. And yes, I have Stephen Kochan's book on Objective-C on my list of books to work through.
But Objective-C, at its heart, is a small suite of extensions to C that add object-oriented capabilities to the language. What this means is that, despite the very different approaches to programming between Objective-C and C, you really need to know C.
Problem is, C is hard if you are coming to the language from a higher-level "scripting" language, as I am.
In general, programming languages work like math. If you remember algebra, you'd have an equation and some variables--x and y--and you've have to find the value of x or y. Programming languages use variables in a similar fashion, to perform manipulations on data.
The difference between a scripting language such as Tcl and C is how those variables, and the operations on them, are established. A scripting language is also called an "interpreted" language--the code in the language is executed by a separate program called an "interpreter." In the case of Tcl, the interpreter is a small program called tclsh. In an interpreted language, variables can be created and manipulated very easily, and the interpreter takes care of all the details of executing the code--making sure there's enough memory for your data, for instance, and making sure that numbers and words are handled appropriately (you can't perform math operations on something that isn't a number!).
In C, and in other compiled languages such as Objective-C, you have to handle a lot of details yourself. When setting up a variable, you have to make sure it's identified as a number (such as an "int," for integer) or word ("char," short for "character"). You have to set up memory for the various tasks your program is going to perform. And then you have to compile your code into an executable program. There's no interpreter involved. (Most interpreted langauges, in fact, are themselves written in a lower-level compiled language such as C--Tcl is written in C.)
So I've been working through an introduction to C programming, co-written by a noted Mac developer, and trying to map what I already know about programming into C. The translation process is an imperfect one, because scripting languages have allowed me to work at a fairly high level of abstraction. I can write code that solves my problems and not worry too much about how my code is actually executed by the computer; the interpreter takes care of that. Picking up a second scripting language (Python) wasn't terribly difficult after I gained proficiency in one (Tcl), because they operate at the same level of abstraction.
Learning C requires a lower level of abstraction. Programming in C requires a lot more interaction with how the computer actually executes your code: allocating memory, for instance. I have to take more steps to allocate and release memory, to make sure all my variables are correctly defined, and so on. It's also slower to develop in C: the code I write in C is actually compiled into machine language, the binary executable that is actually run by the computer's CPU. That explicit compilation step is unnecessary in scripting languages.
Now that I've spent a couple of weeks working through various exercises, it's time to start something real--that's the only way I truly learn something. The current project I'm working on is porting the code I use for generating and validating serial numbers (currently written in a scripting langauge) to C. It's proving harder than I expected, but thanks to some assistance on the comp.lang.c newsgroup, I'm making progress.
Once I get a bit further along, I will be ready to tackle Cocoa more in-depth, because I'll have more of a foundation on the compiled-language level of abstraction. After that, who knows? If I want to do any enhancements to Tcl or Tk, that will have to be done in C.
(Note: I didn't read this article until after I started learning C, but I certainly recognize the attitude contained therein: "Real programmers" program in, or at least know, C. Or, to directly quote the article: "Yep, we C programmers are elitist and proud of it.")
Wed, 09 Jul 2008When you have to make important decisions about your business, it may best to take matters into your own hands. In the case of my Mac software business, I've discussed at some length the Tk-Cocoa project in which another developer is working on moving my preferred toolkit, Tk, from a Carbon foundation to a Cocoa foundation. To date, no progress on this project has been publicly documented.
As a result, I've decided to take matters into my own hands a bit more. I'm diligently working through the new edition of Aaron Hillegass' textbook on Cocoa programming--considered by many to be the textbook on Cocoa programming. While it's slow going (I often feel like I'm taking baby steps), it is going more smoothly than my first serious exposure to Cocoa programming.
I'm not yet sure how I will incorporate my new learning about Cocoa into my software business. Develop and release a full-dress Cocoa application? Port my existing applications from Tk to Cocoa? Contribute to the Tk-Cocoa project--or start the project, if in fact it doesn't really exist? At this point it's too soon to say. But I do feel that getting a good grounding in Cocoa is necessary for the future of my software business--if only to stave off obsolescence, as Apple deprecates and perhaps removes the Carbon frameworks from OS X.
Fri, 13 Jun 2008
Porting a Carbon toolkit to Cocoa: the example of Firefox
This item by the developers of the Firefox browser caught my eye: it's an interesting take on how they are porting Firefox's Gecko rendering engine (the part that parses HTML and displays it to the screen--in short, the foundation) to use Cocoa instead of Carbon. (By way of comparison, Apple's Safari uses WebKit, a different open-source HTML engine.)
Unlike the Cocoa port of Qt, this does seem to result in some user-visible changes. Firefox 3.0 (now in final "release candidate" stage) is much more pleasant to use than Firefox 2.x, in large part because it gets the UI right. Here's an example from Firefox 2.0:
Kinda ugly, especially the button and search field...
Here's an example of Firefox 3.0:
Pretty nice.
It's not entirely surprising to me that the Mozilla developers have taken a different approach with their Cocoa port than the Trolltech/Qt developers. In the case of Trolltech, I understand the goal to be a drop-in replacement of the Carbon foundation with the Cocoa foundation. The changes are supposed to be invisible to Trolltech's customers, which are Mac developers: they are supposed to cause as little disruption as possible. By contrast, Mozilla's update of Gecko coincides with a major update of an application, Firefox: changes are expected and even desired. Many users complained about what they see as Firefox's poor integration with OS X. Firefox 3.0 should address that in a big way.
Tue, 10 Jun 2008
Porting a Carbon toolkit to Cocoa: the example of Qt
Today I was playing with an alpha release of Qt, the cross-platform GUI toolkit, that is built on top of Apple's Cocoa development framework. Trolltech, Qt's developer, has been porting Qt to run on Cocoa instead of Carbon in order to allow its customers to compile high-performance 64-bit applications on the Mac; last year Apple announced that Cocoa would support 64-bit, but not Carbon.
A lot of people (myself included) have complained about Apple's decisions on Carbon. It seemed to us that pushing Cocoa development so strongly would require Carbon developers to do substantial rewrites of their programs as Cocoa applications, but this wouldn't necessarily yield any user-visible benefits. It would amount to a lateral move to the platform favored by Apple, with a better chance of keeping up with the direction of the OS X platform--and nothing else.
Trolltech, to its credit, listened to its Mac customers--they want 64-bit capability. So the company has plunged ahead with its port of Qt to Cocoa: it is the first cross-platform toolkit to outline a definite roadmap to a Cocoa port, and to release working code as the fruits of that effort.
So the alpha release of Cocoa Qt has 64-bit capability. Good. What else has improved, or even changed? The answer is what I suspected: Nothing. The applications look and behave the same as before. When the Cocoa port hits release-quality, end users won't notice anything different at all.
Here's an example of a Trolltech application running on top of Carbon:
If you look closely at these screen shots, they look pretty much the same. The main difference is that the Cocoa application (Qt Assistant) uses the Mac-style unified toolbar, rather than Trolltech's own cross-platform toolbar. But that can't be attributed to Cocoa--the unified toolbar is available to both Carbon and Cocoa applications, and the Carbon version of Qt Assistant also used the unified toolbar.
What Trolltech is doing is re-implmenting its own cross-platform Qt codebase with Cocoa as its foundation, rather than Carbon. When developers use Qt, they use Qt code to build their programs and don't call the underlying, platform-specific code (on the Mac, "QWindow" will presumably call "NSWindow"; I'm not sure what the corresponding calls on Windows and Unix/Linux would be)--that's the purpose of using a cross-platform toolkit. To end users, the fact that Qt's windows are being drawn to the screen by the Cocoa frameworks rather than the Carbon frameworks means nothing.
Of course, to developers and Trolltech itself, there is now one large distinction between Cocoa and Carbon: the former is a better hedge against obsolescence on the Mac. That means the Mac remains a viable platform for them. That is the only reason to move to Cocoa.