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.
OS X and Unix: Unix as a development framework
One of the most prevalent arguments that Apple makes for its Cocoa development frameworks is how easy Cocoa makes things for developers:
"In terms of programming effort, Cocoa gives you, the developer, much that is free and much that is low-cost. Of course, to become a productive Cocoa developer means becoming familiar with new concepts, design patterns, programming interfaces, and development tools, and this effort is not negligible. But familiarity yields greater productivity. Programming becomes largely an exercise in assembling the programmatic components that Cocoa provides along with the custom objects and code that define your program's particular logic, then fitting the whole assemblage together."
In short, while it may take some time to learn the Cocoa frameworks, that effort is richly rewarded down the road by easier and faster application development, and more elegant products.
I have no doubt that this is true. Many of the Mac applications I use daily--such as Safari, Mail, Vienna, and others--are written in Cocoa. They are clean, responsive, well-designed, and a pleasure to use.
Despite the undeniable value of the Cocoa frameworks, however--and despite Apple's promotion of those development frameworks as the preferred method of development on OS X--I'd like to suggest they are not the only route to powerful and even elegant Mac programs. There's a hidden jewel within OS X that provides a different, yet equally empowering, development environment: OS X's Unix underpininings.
Beneath the shiny Cocoa/Aqua surface, OS X is a certified Unix product--which means it has to pass a large battery of tests to be compliant with the rigorous standards of the Open Group, the organization that holds the actual Unix trademark. Apple has continually upgraded and updated the Unix layer of OS X over the years, and passed the tests for Unix certification with the release of Leopard.
What difference does this make for developers? Isn't Unix the ugly, geeky, command-line-oriented, user-unfriendly operating system that is the antithesis of Mac ease-of-use?
Well, yes and no. It is true that many, even most, Mac users have no interest in typing in Unix commands in Terminal. To a user accustomed to pointing-and-clicking a mouse and getting visual feedback, such commands are hard to remember, hard to understand, and hard to follow. As Eric Raymond, a prominent Unix developer and writer about software development practices, notes in his book The Art of Unix Programming:
The CLI style of early Unix has retained its utility long after the demise of teletypes for two reasons. One is that command-line and command-language interfaces are more expressive than visual interfaces, especially for complex tasks. The other is that CLI interfaces are highly scriptable--they readily support the combining of programs....Usually (though not always) CLIs have an advantage in concision as well. The disadvantage of the CLI style, of course, is that it almost always has high mnemonic load (low ease) and usually has low transparency. Most people (especially nontechnical end users) find such interfaces relatively cryptic and difficult to learn.
Despite this difficulty, these small, cryptic, narrowly-focused command-line programs still offer an incredibly powerful resource for developers. In Unix, it is trivially easy to link disparate programs into a larger whole, either via shell scripts, a GUI, or simply calling such programs from another command-line program. If the Mac development philosophy, as embodied in Cocoa, means mastering a complex but powerful framework, using the framework to provide the building blocks of your application, and then authoring the code and functionality that is unique to your application, the Unix development philosophy focuses on understanding how to link together the small, focused command-line tools of Unix into larger wholes, and authoring the code and functionality that is unique to your application.
Raymond quotes Doug McIlroy, who pioneered the concept of Unix pipes (a mechanism for communication between programs that allows the output of one program to be used as the input for another program), on the basics of the Unix approach to development: This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
In short, just as Cocoa provides a framework, so too does the entire system of Unix provide a framework for Mac application development--rapid, powerful, Mac-native application development.
Raymond's The Art of Unix Programming has been a big influence on my thinking about Mac development. The idea that one can build large programs by chaining together many smaller ones, either with a GUI or another command-line program, is very cool--just as cool, in its way, as seeing what is possible with the Cocoa frameworks. I got my first exposure to the command-line five years ago, when I was trying to set up an iMac running OS X Server and had to edit a number of configuration files: all the documentation said to fire up Terminal and type in "sudo pico filename.txt." Huh? I had no idea what I was doing, but followed the instructions--and as I did more and more of this, I began playing around with the different command-line tools. In at least one instance, learning these command-line tools saved my server from being hacked.
But even as I saw the power of these tools, I also encountered frustration. They were hard to use, and required too much typing. It was in that observation that I saw a commercial opportunity: provide elegant Mac GUI's for these command-line tools. In doing this, I'm not the first: there's a long tradition of developers on Unix doing just this with GUI toolkits such as Tk, a powerful but lightweight GUI toolkit that first developed on Unix. (One of the most comman names for GUI applications on Unix is TkFoo, in recognition that a Tk GUI is driving a command-line tool named "foo.") A number of Cocoa developers on the Mac have done this with various command-line tools as well: it's not uncommon to see Cocoa GUI's, written in Objective-C or AppleScript Studio, for simple command-line tasks. (I've lost count of how many free tools there are for packing and unpacking zip file archives, for instance.)
Although I also use Tk as my toolkit because of its combination of simplicity and power, I'm trying to do more than assemble the latest iteration of "TkFoo." As Cocoa developers do with their framework, I'm trying to leverage the power of Unix to build elegant, sophisticated Mac programs. For example, my program PortAuthority provides a GUI for the MacPorts Unix software system on the Mac--but it's not a simple wrapper for the MacPorts command-line "port" tool. It begins by driving "port" and parsing its text output, but adds value by making it simple to browse MacPorts programs by category, something the MacPorts command-line program doesn't do; it also, via different command-line tools, the next version of PortAuthority will hook into such Mac-specific technologies as Growl for user notifications.
Another example: I am currently developing a file search tool with Growl, Quick Look, and Core Image integration, as well as other features, all achieved with command-line tools. The GUI provides the high-level view of the data and drives the various command-line utilities under the hood to get the requested data.
It's important to understand that although I'm using a GUI toolkit that originated on Unix, and using a design philosophy that differs from Cocoa programmers, I'm still striving as much as possible to meet Mac user expectations, something I've written about before. Using a toolkit other than Apple's featured one does not relieve me of my obligation to make my programs meet Mac user expectations, adhere to the platform's recommended UI guidelines, and so on. I do this, to the outmost extent permitted by the toolkit and by my own skill. Based on the sales my programs are achieving, I think I'm doing a decent job on that front.
To a large degree, my perspective on Mac development is a hybrid one, joining both the Unix and the traditional Mac approach. Raymond summarizes these two perspectives well:
Macintosh programmers are all about the user experience. They're architects and decorators. They design from the outside in, asking first "What kind of interaction do we want to support" and then building the application logic behind it to meet the demands of the user-interface design....By contrast, Unix people are all about infrastructure. We design from the inside out, building mighty engines to solve abstractly defined problems...We then wrap thin and often profoundly ugly interfaces around the engines.
I want to leverage the powerful engines, but I still want my applications to be all about the user experience.
I am troubled by Apple's promotion of Cocoa to the denigration of other GUI frameworks; in particular, Apple's relegation of Carbon to second-class status presents difficulties for developers using toolkits built on top of Carbon, which includes Tk. (Fortunately, Jason Slack's plan to port Tk to run on top of Cocoa mitigates this concern. Once Jason has released a stable port of Tk-Cocoa, I will even be able to claim, if only technically, that my programs are Cocoa applications.)
Despite my misgivings about the privileging of Cocoa, however, I must give Apple full credit for the investments and improvements it has made in the Unix components of OS X. This includes providing command-line, Unix-style access to many Mac-specific technologies, such as Core Image and Quick Look. Without the power of Unix under the hood of Mac OS X, my own work as a developer wouldn't be possible.
Not only does Unix provide a powerful framework for Mac development--it also provides a powerful platform for Unix developers to pursue commercial development opportunities. On other Unix platforms, most users don't pay for the software they use--the culture expects free software, both in the sense of free to tinker with the source code, and free as in "no-cost." The Mac culture, however, is one where uses support independent commercial developers. On another Unix platform, it's unlikely that I'd earn any income at all from my software work.
It would be nice if Apple promoted Unix as heavily as they promote Cocoa. But the fact that they make Unix a first-class development platform on OS X (unlike, for instance, Carbon) is good enough for me.
Fri, 23 May 2008For the past couple of years I've been informally maintaining a Python/Tkinter wrapper for the Tk themed widget set, or ttk. This was adapted from a long-lost module first developed by Martin Franklin. I've used it in various projects, most extensively in Phynchronicity, and I've updated it as the ttk widgets have evolved and my own needs required. I'm not, however, enough of a Python wizard to completely implement the ttk widgets in Python.
Now I don't have to. Guilherme Polo has launched the Ttk to Tkinter project to provide the comprehensive Python version of the ttk widgets, under the auspices of the Google Summer of Code. The scope of his project is impressive: to add complete Ttk support to Python's core Tkinter library; to provide documentation; to migrate the standard Python editor, IDLE, to use the Ttk widgets (currently it uses the core Tkinter widgets, and looks rather outdated); and to provide sample code to illustrate how developers can use the widgets.
This is very cool indeed. When complete, this project will fully modernize the Tkinter widgets, which have tended to lag behind developments in Tk itself, and make Python/Tkinter a contender again in the GUI development races.
A complete overview of Guilherme's project can be found here.
Sun, 18 May 2008I've just released Manpower, which provides a GUI for viewing man pages on OS X.
This isn't the first program of this type that I've developed. For two years I developed VuMan, another man page viewer--first as open source, then as commercial software, then put out to pasture as open source again.
If you download and play with VuMan, you'll see that it has a somewhat clunky interface. I could never decide what I wanted the program to be--a viewer? A browser? A complete listing of man pages on your system? A tool for saving man pages in various formats? It did all of these things, but it made the program somewhat difficult to use. VuMan was also sluggish, calling out to multiple Mac command-line tools any time a user pressed a button.
Manpower is significantly different than VuMan. It lists all the man pages on your system, but it uses a more coherent design: it uses the same three-pane interface that Apple's Mail program, and iTunes, use. Man pages come up with a click of the mouse, not with selecting and pushing multiple buttons. Manpower also saves man pages, but only in basic text format.
Simplicity is the key here. By simplifying the feature set and design of the program, I think I've made it much easier and more pleasant to use. I have a few ideas of additional features to add, but they will be added sparingly--in a way that is consistent with the lightweight design of the program.
Not coincidentally, Manpower's simplicity and elegance is why I think the program justifies a $19.95 price tag. There are a lot of free man page viewers out there, but they either do less than Manpower, or are (in my view) more complicated to use. I don't think there's a free man page viewer out there (including VuMan) that is as clean and elegant as Manpower. I hope you'll agree.
Tue, 06 May 2008My strategy for porting my programs to Cocoa is becoming a bit clearer.
It appears that Jason Slack's project to port the core Tk libraries to Cocoa isn't vaporware. While he has not posted anything public about it, I've had a bit of private correspondence with him, and it seems that he has gotten under way. I've offered him assistance with testing and other feedback, so we'll see what comes of that. The long-term goal is to simply replace Tk's current Carbon implementation with a Cocoa-based implementation in my programs. In the meantime, I am working on removing my own applications' dependencies on Carbon, at least the dependencies I myself have added.
As one example, my programs make some use of Daniel Steffen's Carbon extensions, and I'm working on achieving that functionality by other means. So far I've been able to find what I need. For instance, one function in the Carbon library involves determining which program is frontmost on the user's screen, and bouncing the icon on the dock if my program is in the background; I've found I can get the same data by using AppleScript to call the Mac's System Events application.
Another example involves the user documentation of my programs. Currently I use Apple's Help Viewer application for my user help. I format my documentation according to Apple's guidelines, and use a Tcl extension I wrote myself, tclAppleHelp, to load and display the help. Eventually, I will be moving my user documentation online, to a special section of my main website, which I will load with a call to Apple's command-line "open" tool (which opens a document in its default application). This will remove another dependency on Carbon, and also work around the annoying behavior of Apple's Help Viewer in Leopard (the help window floats on top of all other applications). It may also help the visibility of my programs on Google, as there will be more material (user help) about them posted on the Internet.
In the coming months I'll be making these changes, and others, to my existing programs, as well as including them in new products under development. Now that the Cocoa port of Tk itself is under way--a task that I can contribute to, but which is too large for me to undertake myself--I feel energized to resume development of my own programs, and I'm bursting with ideas. What a wonderful thing to be able to concentrate on improving my applications for my customers, rather than rewriting them in an entirely different framework.
Fri, 11 Apr 2008It seems there is no escaping the ascendancy of Cocoa for Mac OS X developers. Since Apple announced last summer that it was moving its Carbon frameworks into maintenance mode-- with only bug fixes being made and no new features, like 64-bit support, being added--the long-term tides are running even more strongly against Carbon than I realized:
- The removal of Carbon from the standard library in Python 3, the next generation of one of my core development languages. I only depend on a few Carbon libraries--the ones that support Apple's help system--but having that removed will require some adjustment on my part before I move to Python 3.0.
- Jason Slack has announced plans to port the GUI toolkit I use, Tk, to run on top of Cocoa--but this will probably break a lot of Carbon-dependent Tk libraries that I and other developers use, and these may need to be rewritten to use Cocoa.
- Even one of the most venerable Carbon applications, Adobe's Photoshop, is now moving to Cocoa: Adobe has just announced that a Cocoa port of Photoshop is underway. Carbon was first implemented as a transition from the old Mac OS 9 to OS X in large part to ensure the continued support of the Mac platform by commercial developers such as Adobe and Microsoft. Given the size and complexity of applications like Photoshop, it is not surprising that a Cocoa port has not been announced until now; now that it is happening, however, it is hard to see Carbon's days as anything but numbered.
I've kind of halted work on new versions of my program for the time being to improve my facility with Objective-C, Cocoa's foundational development language. It is becoming more and more clear to me that I will have to integrate Cocoa into my work to a significant extent. It is simply unavoidable. Even if I do not completely rewrite my programs from Tcl and Python into Objective-C, it is obvious that I will have to know Cocoa and Objective-C to modify certain components I use. And it is difficult to imagine a single person being able to rewrite Tk Aqua from Carbon to Cocoa without some help.
The question for me is which path makes more sense, in terms of time: learning Cocoa, then rewriting my applications in Cocoa; or learning Cocoa, then rewriting the underlying toolkit of my applications in Cocoa. I don't know enough yet to make that decision. But, one way or another, Cocoa is becoming part of my work.
Wed, 19 Mar 2008
Tcl/Tk and Google Summer of Code
The Tcl/Tk community has been accepted as a sponsoring organization for the Google Summer of Code. The Summer of Code is a program that offers student software developers the opportunity to contribute to open-source projects, supported by a nice stipend and guided by experienced mentors.
While no official projects are yet underway, I see two on the Tcl community's proposed list that are of particular interest to me: "TkCocoa" and "Tk Drag&Drop: Native OS X (Aqua) port." Both would greatly improve Tk on the Mac, and help to ensure its long-term direction.
Mon, 03 Mar 2008
Market forces, customer needs, and business success
A couple of developments this past weekend prompted some thinking on my part about the software business, customer needs, and fashion.
First, David Watanabe, a well-known independent Mac developer, announced that he was making his NewsFire newsfeed reader free. Previously it had been a shareware product requiring a registration fee.
Second, Dave Taubler, a cross-platform Java developer whom I've never heard of, released a point update to OverSite, a website-design tool. OverSite is a shareware product that requires a registration fee.
Watanabe is well-known among the Mac user and developer community for, among other things, the elegance of his programs. They are, quite simply, beautiful. They show the full potential of Apple's recommended Cocoa developer frameworks.
Taubler isn't a semi-celebrity in the Mac community. Looking at his website, he appears to have a day job, and develops shareware part-time, using Java as his chosen technology. By contrast to Watanabe, users don't find Taubler's application beautiful.
Why am I comparing these two developers and their software? Because it appears that, although Watanabe has the shinier product--a beautiful Cocoa newsreader--Taubler's plain-Jane Java program is the more financially successful program. How do I reach this conclusion: Simple. Watanabe has apparently concluded that there is no paying market for NewsFire, and has made it free of charge. Taubler, on the other hand, continues to charge for his program.
How can a Java program do better than a Cocoa program on OS X? Such a development runs against every bit of conventional wisdom that one sees in the Mac developer community. I see several reasons for this.
One factor is that markets change and evolve, and in the specific instance of Watanabe's market--desktop newsfeed readers--the paying market is imploding. There are numerous free, web-based feed-reading services, such as Google Reader. There are numerous free desktop readers such as Vienna. And finally, the leading Mac desktop RSS client, NetNewsWire, became free; its corporate owner decided, in the words ofits developer, that "the software is great marketing for our enterprise software; and the more users we have, the better able we are to calculate relevance and importance."
In short: desktop RSS clients are now like desktop web browsers and e-mail clients: a commodity that few users will be willing to pay for. This development hasn't discouraged at least one other developer of a desktop RSS client, but it is clear that this market segment is now exceedingly difficult.
Taubler's market--web designers--is a smaller one, not growing exponentially like the RSS client market used to, but it is also more likely to include paying customers who use the software professionally. Consequently, while there are a number of competitors at several price points, it is possible for a software product with a specific, specialized feature set to find a place in the market.
Another factor in an application's success, apart from its market growing or drying up, is how well the applicaiton works and how well the developer supports the application. Users apparently find Taubler's application functional. It does what they need it to do. Users also seem to find him to be a responsive developer.
Users seem to have some serious issues with Watanabe's approach to customer service and the stability of his programs. I'd say that opinions of his customer service and application stability run as strongly to the negative as opinions of his application design run to the positive.
While one shouldn't base an opinion of a developer or product entirely on comments posted at a download site, those comments do offer useful information--especially if they seem to converge on a consensus. In the cases of both developers, they do: one is considered unsupportive, the other is considered supportive.
So what lesson am I trying to draw here?
The lesson is that there are many factors that influence the success of an application. One's choice of technology is, based on my observation, a minor factor. Making a fetish of your chosen technology, touting it as a feature in itself rather than something that enables useful features, strikes me as misguided. Targeting the right market, offering helpful user support, and most of all, providing a stable application that solves the user's problems--these are the most important ingredients for success.
A beautiful Cocoa design was apparently not enough to make NewsFire a profitable application for David Watanabe--not when the application's market was imploding, and when many users recommended against purchasing the program because of their own experience with customer support. By contrast, although users seem to find Dave Taubler's application a bit unpolished in terms of its design, its specific functionality and the developer's customer support make it a worthy purchase--even in a market segment that offers several alternatives.
This is a lesson I'm taking to heart myself. I have tried to continually improve the design and the functionality of my programs, and provide good customer support. I'm also continually looking at different market niches as I research potential new products to develop. But I'm not continually reassessing the technologies I use to develop my programs--I am leveraging their strengths and working around their limitations, but most importantly I am using them to develop software that customers find useful, and will pay for.
Sun, 24 Feb 2008A couple of weeks ago I got an e-mail from a member of the Oxygen icons team, my primary source for application and toolbar icons, asking me to clarify the terms of use of the icons. Because I'm using the icons freely under an open-source license (see the credits page on my website for details), I gladly complied.
Open-source code is a terrific resource for commercial developers, because it can save a lot of time and cost--I don't have to develop these items myself. Of course, it's incumbent on me to use the software in a manner that's consistent with their license. Some open-source code can only be used in other open-source projects, while others can be used in commercial products as well. The components I use come with commercial-friendly licensing terms.
I think it's important to do more than simply comply with the terms of an open-source license, however. I try to contribute to open-source projects as well. I've contributed documentation, bug reports, code patches, and code samples to the Tcl/Tk and Python software communities. In addition, I maintain an entire suite of software extensions and packages here. Whenever I develop a code package that improves my software and that I think can benefit others as well, I release it under an open-source license. (See http://tk-components.sourceforge.net/mactoolbar/index.html for one component that worked its way into my products over the past few months.)
In fact, that's what I've been working on the for the past few weeks--some open-source components that will eventually become part of new commercial products and my existing products as well. These components are geared toward improving the user interface of my programs, and will allow me to develop more polished products. It's my hope that other developers will be able to make use of my projects, much as I've been able to make use of the open-source work of others as well. That's what giving back is all about.
Thu, 24 Jan 2008As part of the new releases of all my software, I've raised their price: from $20 to $24.95. This might raise a few eyebrows, especially since these are all point updates (for example, from 2.0 to 2.1), and the improvements are refinements of existing features and bug fixes, not a laundry list of new whizbang features. Most price hikes tend to come when a program is bumped from 2.4 to 3.0, and when the software vendor can point to "300 new features!"
I believe the price hikes are justified, however. There is value in continuous refinement and improvement, just as there is value in substantial new functionality.
The changes I've made to my products make them first-class citizens on Leopard, for instance. Shiny new 512-pixel application icons, toggling toolbars, full integration with Leopard's new floating "help" window, no more crashes when saving files, and more. And they retain backward compatibility with Tiger, to boot. These changes represent a lot of work over the past few months. Prior to that, my programs underwent a similar course of evolution: not a lot of new features, but dramatic refinements and simplifications in the user interface, as well as improvements and additions to the user documentation, so that they became more intuitive and pleasant to use. And most of these releases were made as point updates, not entirely new versions.
Over the course of a year, this represents a substantial amount of development work in each program--and substantial improvement. When I was testing the software update feature in each of my programs, I unarchived and used versions that were about 18 months old. They had pretty much the same functionality as the new versions, but they were almost painful to use--it's a wonder I sold any licenses at all, at any price.
So the price increase today is a reflection of the increased value of my software. Relative to competing products, my programs are worth the price I'm charging. Their feature set, elegance, and documentation surpass the free competition, and offers a better value than higher-priced competitors.
After a final push, new versions of PortAuthority, Phynchronicity, and PacketStream are ready. Enjoy.
Wed, 23 Jan 2008Tcl developer Mark Roseman has put together TkDocs, a website that aims to serve as a resource for developing GUI's in Tk. It's not just a tutorial site, however--its goal is to be a complete resource, with discussions of Tk widgets, lots of screenshots, and (still in progress) screenshots of state-of-the-art Tk GUI's. When the site is complete, it should be an excellent starting point for anyone developing graphical interfaces with Tk.
Hey, Mark--feel free to poke around here if you need some material for the "gallery" section...
I've been doing a great deal of work updating each of my programs--PortAuthority, Phynchronicity, and PacketStream. The focus of these releases is Leopard compatability, updating the GUI base of my applications to Tk 8.5, and various refinements and improvements.
Making my applications Leopard-compatible means, among other things, changing their icons yet again. Apple has added a new 512-pixel application size for Leopard, which is much bigger than those supported by previous verisons of OS X. (Think 128 pixels.) Last year I purchased commercial icon sets from two vendors (WackyPixel and IcoZon), to use as my application and toolbar icons. These icons, however, weren't available at 512 pixels. As a result, I've switched to two excellent open-source libraries, Oxygen and Crystal, both of which are part of the KDE project. These icon sets blend in very well with OS X and can also scale up to 512 pixels.
Another part of Leopard compatibility is improved stability, courtesy of Tcl/Tk 8.5. Tk, my GUI toolkit of choice, recently hit a landmark release, as the new version is the biggest improvement in several years--it offers greatly improved integration with OS X. The older version of Tcl/Tk that I used (8.4.16) was also crash-prone on Leopard; 8.5 fixes several bugs in that respect, and my programs should run without a hitch now.
I've also added some new Tcl/Tk packages such as the TclMacBag library, which supports some custom Mac-style widgets that are not part of the core Tk library. This package has also helped me improve the look and feel of my programs in some respects.
Importantly, I am trying to maintain backward compatability in all of my programs: all have been tested on Tiger (OS X 10.4) and seem to run fine. Not everyone upgrades to the latest OS right away, and I want to support those customers still on Tiger.
I'm very pleased with the improvements I've made, and I hope you will agree once the programs are available. Look for them soon.