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, 21 Dec 2007
I've been quiet lately, but not idle. After deciding against moving to Cocoa as the basis for developing my programs, I began working on various improvements to my applications--further polishing up the user interfaces, improving Leopard compatability, and importantly, integrating Tk 8.5 into my programs.
Tk 8.5, four years in the making, has a vast number of improvements, including better Mac integration, nicer text rendering, and various other spiffy UI bells and whistles. Integrating these goodies into my programs will take a bit longer than expected because there's an unexpected wealth of stuff there. But it will be worth it.
Mon, 26 Nov 2007Bloody hell. Cocoa isn't any easier than Carbon.
I've been working through the Bible of Cocoa programming, Cocoa Programming for Mac OS X by Aaron Hillegass. Hillegass is a good writer, and he tries mightily to make the Cocoa frameworks accessible. But they are difficult and complex. What makes them even harder to learn is that my heart simply isn't in it: I have no interest in Cocoa apart from what Apple has coerced.
I have become so productive with Tk as a GUI programming framework, accessed from the Tcl and Python programming languages, that I'm quite content to continue working in that vein. The programs I've developed in these languages are non-trivial. Porting them to Cocoa not only requires me to learn Cocoa, but to unlearn my present means of working. And this holds true whether I access Cocoa from the low-level Objective-C language or use a higher-level wrapper, such as PyObjC.
So instead of marching through Cocoa hell, I'm saying: to hell with Cocoa. I'm not rewriting my programs, thousands of lines of stable, debugged code. I'm sticking with Tk.
Of course, this doesn't alleviate my earlier concern that Tk is built on top of Carbon. Other cross-platform toolkits using Carbon have outlined plans to integrate Cocoa. Not so for Tk, at least not yet. I feel bad that I don't have the low-level chops to contribute toward porting Tk to Cocoa. I will instead release as open-source some of the Tk code I've developed recently to improve the Mac look-and-feel of my programs: that way others can benefit from the work I've done.
Based on a recent mailing list thread, I have faith that Tk will continue to evolve to the degree necessary to remain a viable development environment on OS X. I may not have the skills to ensure this, but others do. Tk may never be cutting-edge, but that's OK.
Mon, 19 Nov 2007Things have been pretty quiet here lately: I still haven't updated to Leopard, but will do so in the near future. I will be making new Leopard-compatible releases of my software at that time. These will focus on bug fixes rather than substantial new features.
Though I haven't released anything for several weeks, I have been doing a lot of coding, and thinking, about the direction of my programs. Part of this process has been learning the C programming language. Learning C has gone smoothly enough, at least to the point where I can read C code and understand what's going on, more or less. That's a necessary precursor to being able to do productive work in a programming language.
Unfortunately, the next step of my roadmap--learning Apple's Carbon frameworks to help enhance the toolkit I use for my programs, Tk--has gone unexpectedly awry. Simply put, there are no usable, modern resources to learn Carbon. The few available books on Carbon programming are generally obsolete, even though they were published to coincide with the release of Mac OS X. Apple has made huge updates to the Carbon frameworks since OS X was released, but no "introduction to Carbon" documents--whether books or provided directly by Apple--reflect these changes. As a result, if you are a newcomer to Carbon and need to rely on a textbook to learn the basics, you will learn only obsolete things, which you will then have to unlearn in order to adapt to the modern approaches.
Whether by design or happenstance, aspiring Carbon developers are being starved of resources they need to learn the frameworks. This, as much as Apple's deliberate decision to make Carbon a second-class citizen for Mac development, helps to ensure that Carbon eventually will wither away.
As a result, helping out with enhancing Tk is starting to look less and less like a viable option. Getting Tk to do what I want--display Mac icons natively, fully supporting drag-and-drop--will require climbing a learning curve nearly vertical in its difficulty. I'm not a C programmer by trade, nor am I really interested in becoming one. I gravitated to Tcl/Tk and Python/Tk precisely because I thought they wouldn't require me to be a C programmer. The amount of work required to become a Carbon programmer in order to enhance Tk is vastly increased by the paucity of resources for learning modern Carbon programming, and makes the entire enterprise simply daunting to me.
So what does this mean for the future of my programs? Well, they definitely have a future. The question is what direction I take them.
Thu, 25 Oct 2007After several false starts, I'm working on adding a third major programming language to my toolkit, complementing Tcl and Python: C. C is the lingua franca of computer languages, a fast, compact, compiled language that is the basis of operating systems (huge portions of Mac OS X, Linux/Unix, and Windows are written in C), other computer languages (Python and Tcl, both dynamic, interpreted languages, are themselves written in C, while such powerful languages as Objective-C and C++ are additions to C), and such workhorse programs as the Apache web server are written in C.
The problem is, learning C is hard--it's much harder, less forgiving than the scripting languages I'm used to working with. It requires the programmer to do such things as manage memory; it forces you to be very strict in how you set up your code. It's also slower to work with. Instead of saving my code to a script file and then running my code in a dynamic language interpreter, I have to compile my code each time; an interpreter runs the code interactively and immediately, which makes it easy and fast to change your code, but compiled code must be re-compiled each time you make a change.
Given these hurdles, I can't say I'm having a lot of fun learning C--even though I'm still doing very basic stuff, and I'm using a textbook by a well-known Mac developer, Marc Liyanage (see http://www.entropy.ch/blog/2004/10/22/Our_New_Book_About_C_Programming_is_Out.html). Working in C reminds me of why I gravitated to scripting languages in the first place.
So why learn C at all?
The chief reason is that scripting languages, for all their power and ease-of-use, have limitations. Their capabilities are baked into the language by C, and if you want to do more than the languages allow, you need to drop down into C. For instance, Tk (the GUI toolkit that I use, with both Tcl and Python) is very flexible and configurable, and I can tweak many parts of it to get my programs looking very native on the Mac. (See here for some discussion of this and a screenshot.)
However, some things can't be done from within the toolkit or language itself: the toolkit itself needs to be changed. A good example is the way Tk displays notebook tabs on OS X. Here's how my programs display notebook tabs:
Does that look a little out of place? Yes, it does--Tk uses a fairly old Apple C function (specifically, the Carbon Appearance Manager API) to display tabs. This particular method has been out of date since Apple shipped Panther (OS X 10.3) in fall 2003. This style of tab still exists in OS X, since removing it might cause programs to break, but the more modern style is displayed below:
Changing the way Tk displays notebook tabs will require some modifications to Tk's source code in C--specifically, to call the newer Carbon HITheme API rather than the Appearance Manager. I'll work up some new code to do this, and once it works, I'll submit it to the core Tk developers as a patch. That way, all Tk programs on OS X will benefit from the update.
That's just one example. There are others, but I can only tackle one project at a time.
Learning C is helpful if I ever decide to delve more deeply into Apple's Cocoa frameworks, because the core language of Cocoa--Objective-C--is based on C. However, it's more likely that I will concentrate on using what I learn from C to enhance Tk.
I haven't yet tested my programs on Leopard, but I don't anticipate any major difficulties. I plan to delay upgrading to Leopard for a brief period so I can do one more release of each program--PacketStream, Phynchronicity, and PortAuthority--to smooth out the transition to the new OS. After that point, my efforts will focus on supporting Leopard, and working to ensure that my programs offer the best user experience on that version of the OS. An older, Tiger-compatible version will continue to be available for download for users who do not upgrade to Leopard, but no new work will go into enhancing them.
Tue, 09 Oct 2007I've released Phynchronicity 2.0, my GUI for the Fink Unix software management system. As I noted previously, this new version incorporates the many improvements I've made to the design, usability and documentation of my other programs as well. If you use Fink and are looking for an intuitive GUI for it, Phynchronicity is worth trying out.
Fri, 05 Oct 2007
Phynchronicity 2.0 in the works
I'm currently working on a major update to Phynchronicity, my GUI for the Fink Unix software package system. This new release incorporates the GUI overhaul that I previously developed for PortAuthority and PacketStream.
It's taken a bit longer than I expected to get the new update finished. One reason is that this is a larger update than the other programs: I phased in the changes to PortAuthority over two or three releases instead of one, and PacketStream required fewer changes because it's a slightly simpler program. Also, because Phynchronicity is written in Python instead of Tcl, the code libraries I developed to improve the layout of PortAuthority and PacketStream required some adaptation to work with Python--or had to be re-written in Python altogether. Finally, some of the update issues are simply specific to Phynchronicity--for instance, what's the best way to get all the information I want into a display if Fink (the underlying command-line tool that Phynchronicity drives) doesn't provide this data easily?
I'm pleased with the result; what's left to do is testing and updating of the user documentation. I can't wait to get the new release out. In the meantime, here's a preview of the new version:
I've released an update to PortAuthority, my GUI for MacPorts. This release focuses on improving the user experience for those trying out the program for the first time. Previous versions of PortAuthority would throw up a huge number of windows on first launch--a preferences window, a "do you want to buy" dialog, and so on--that made it hard to get started. Version 2.4 streamlines this process greatly by reducing the number of startup windows and fixing several bugs. This release also fixes some minor glitches with scrolling the tree view, and adds a "contact the developer" command to the help menu, to improve user support. If you use PortAuthority regularly or want to try it out, this new release will interest you.
Thu, 13 Sep 2007
VuMan and NameFind now open-open source
I have released free, open-source versions of NameFind and VuMan, two commercial applications I recently discontinued. I've done this in response to a query from a registered user of one of these programs. I also continue to make use of both programs; although they did not attract much of a commercial user base, I believe they are still useful.
The only real update for these new versions was to remove some proprietary components, such as icons, code for managing software updates, and so on; I also updated the documentation of each program. However, neither has undergone the extensive redesign I've given to programs such as PortAuthority, and I do not anticipate updating these programs further in the future.
NameFind can be downloaded at http://ireveal.sourceforge.net, and VuMan can be downloaded at http://vuman.sourceforge.net. Enjoy.
Wed, 29 Aug 2007
Branding: "Making Unix Easy on Mac OS X"
One of the things you'll notice at my main website is a new branding emphasis: "Making Unix Easy on Mac OS X." All of the programs I write provide graphical user interfaces to Unix command-line utilities on the Mac. Two of the programs--PortAuthority and Phynchronicity--provide an easy way to manage the installation of Unix software on the Mac, with GUI's for the MacPorts and Fink software packaging systems. The third program, PacketStream, provides a similar interface to the tcpdump network monitor.
All of these command-line tools are powerful and can be easily accessed if you have Unix command-line chops. However, many Mac users who might be interested into tapping into the power of these applications don't necessarily have the command-line knowledge to do so. That's where my applications come in; users are willing to purchase them to tap into the power of the command-line.
For me, this is the real joy of programming on the Mac. It's the combination of the insanely powerful Unix underpinnings and the elegant Aqua interface. This commercial niche simply doesn't exist on any other platform. There are lots of command-line tools on Unix, and a large number of graphical interfaces for them--but Linux users simply don't pay for software. And while Windows users do pay for software, the Windows command-line environment is pretty anemic; there simply isn't much there for a GUI to tap into.
Many Mac developers praise the Mac because of the cool things afforded by the Cocoa programming environment. That's great for them. But I'd also suggest that the Unix foundation of the Mac is a secret weapon for the platform as well; at least, it's where I've found a very fruitful place to work. And I'm only just beginning!
As you've probably noticed if you are looking at this blog, I've tweaked the look of the blog--adopting the standard Mac font, Lucida Grande. But that's only a small change compared to the major update at the main Code by Kevin site. The new site is much cleaner, more modern and Mac-like, easier to navigate, easier to digest, and (good for me) easier to maintain. Thanks to many folks at the Mac Software Business list for a lot of feedback.
Tue, 28 Aug 2007Lest you think that I'm only discontinuing applications...
PacketStream 2.2 is now available for download. This is a fairly major overhaul of the user interface, and also adds a good amount of documentation on how to use PacketStream, how it interacts with the command-line program that serves as PacketStream's engine, and more. Both the UI and documentation updates are in response to user feedback, whether voiced to me privately or posted online at download sites.
If you're looking for an inexpensive and easy-to-use GUI network monitor, PacketStream hits a sweet spot. Give it a try.
Thu, 23 Aug 2007I've decided to discontinue VuMan, my man page viewer. Like NameFind, which I previously discontinued. VuMan has sold very poorly. It targeted an extremely narrow niche, and had a great deal of free competition. In deciding whether to update its interface or not, I concluded that it would take a great deal of work to add the features I wanted, and the return on that investment would likely be poor.
Fri, 17 Aug 2007
When to discontinue an application: R.I.P., NameFind
I doubt this announcement will cause much grief, but I'm making it anyway: I'm discontinuing NameFind, my file search tool for OS X. It's been removed from my website and is no longer available for download.
NameFind was first released in Feburary 2006; I had begun working on it in the fall of 2005. I developed NameFind because I was unhappy with the built-in Spotlight search technology on Mac OS X. Thought powerful and free, Spotlight was complicated, and many users besides myself expressed frustration with its limitations; furthermore, many other products, both free and commercial, had been released to improve the Spotlight experience.
In designing NameFind, I decided to use a different technology than Spotlight, which organizes its information into a continuously updated database on OS X. I decided that NameFind would be a GUI for the Unix "find" command, which crawls your file system in real time looking for files or directories that match the search term.
After a couple of initial releases, I had the search aspect working well. NameFind would run its search command, looking for files in a specified directory and its subdirectories, and return the data. However, that wasn't enough to make it a successful application. The external "find" command was somewhat slow, and some reviews of NameFind complained about this. Other reviews complained that NameFind was ugly. Finally, many reviewers questioned the need for a commercial search tool when Spotlight and other free alternatives were available.
As a result, NameFind has sold hardly at all--less than 10 licenses in 18 months of release. And it's hard to justify continuing to put my own time and resources into continuing its development.
I've learned some interesting business lessons from this experience:
-
Some of the cosmetic limitations of my programming framework, Tk, can be worked around. However, there are some limitations that are more difficult to avoid. For instance, Tk lacks built-in facilities for accessing Mac icons; this make displaying data from the file system, such as the contents of a directory, difficult. I had to decide between showing no icon at all, which was too minimalist; using generic icons, which was jarring in its contrast from other Mac applications, such as the Finder; or finding a way to access system icons, which, while possible with the help of external programs, was cumbersome.
The conclusion I draw from this is that Tcl/Tk is not a good framework for Mac applications that need to display file system views. In this instance I might have been better using a Mac-native framework, specifically Cocoa.
-
If your application has a large amount of free competition, you may be in trouble unless your application offers clearly superior features that users would be willing to pay for--this is especially true if your competition is bundled with the OS you're running on. In the case of NameFind, it was slower, uglier, and more expensive than the free competition: it's hardly a surprise that it sold poorly.
-
An additional item about competition: the more crowded the category you're targeting, the harder it is to stand out. If my only competition was Spotlight itself, I might have stood a chance, but there are several "Spotlight alternatives" out there--and a larger number of file search tools.
My work on NameFind has certainly been a good learning experience. It's taught me a lot about what to do, and what not to do, in terms of marketing, choices of technology, and more. And, with the insights I've gained, I'll turn my attention back to developing the four other applications I've released, and which sell much better than NameFind.
Wed, 08 Aug 2007PortAuthority has gotten a terrific review on VersionTracker. And sales are already starting to come in; usually it takes at least a few days before a new release results in sales.
It's been a good day, and all this definitely validates the direction I've set for my software. Onward!
I've released version 2.3 of PortAuthority today. Apart from being faster, cleaner and more intuitive to use, I think this version represents the final piece of the look-and-feel puzzle that I've been working with for several months: things look familiar, and work in the way you expect. Clicking on something once causes data to display in the standard manner. Entering a term in the search bar and hitting return runs a search query. There should be a lot less adaptation required to use PortAuthority; no more "this looks like a search field, I guess I'll enter text here"; no more "a single click didn't work, I'll try a double-click."
I consider this a milestone release, not just for my users, but because what it represents to me in terms of my own growth as a developer. I've pushed hard to learn how to make my applications more usable, more intuitive, more Mac-like. I've gotten a lot of user-feedback, some high-level and some very fine-grained, that has helped me target what changes to make in the look and behavior of the program; and I've learned how to implement those features using the resources of my programming toolkit, Tk. Once I learned exactly what UI behaviors to target, finding (or implementing) the appropriate functionality in Tk wasn't difficult; Tk is rich enough to support these things, as rich as Apple's Cocoa frameworks. I haven't wasted my time in working with Tk; whatever issues my programs have had stem far more from my own limitations, rather than the limitations of my toolkit.
It's all about learning and growth: listening to user feedback, researching how to implement what they're asking for, and then getting it right, whether on the first try or through trial and error. It's also about leaning on the expertise of a larger community, finding open-source components when my own skill (or time) is insufficient for a specific feature, and in turn contributing my expertise to that community when I am able to do so.
All the work I've done in the past several months streamlining the UI of PortAuthority has not only led to a better program, but a better developer. It's going to be very easy for me to implement the things I've learned in my other programs. And it will also be easy for me to contribute some of the fruits of my work back to an open-source community, in the form of easy-to-use code components. And finally, both users and myself will benefit from this: users, through easier-to-use programs; and myself, through increased sales of software.
So: if you use MacPorts, give PortAuthority 2.3 a try. You won't regret it.
Thu, 02 Aug 2007
Listening to user feedback: look and feel
Based on some feedback from users, it appears I've finally gotten the "look" of PortAuthority right. However, the "feel" isn't quite there yet. Here's a rundown of issues identified by one user in an e-mail to me:
-
Things that should work with a single-click require a double-click--for instance, filtering ports by selecting a category in the tree view.
-
Things that should work with a single-click don't work at all--for instance, getting the information about a port with a single-click in the table view.
-
Things that should happen infrequently happen all the time--for instance, the program beeping an alert when it completes an operation.
-
Things that should stay the same get changed abruptly--for instance, when a package is installed, the table view shifts to the complete list of packages, rather than updating the existing view.
-
Things that should happen quickly take forever--for instance, filtering packages by category.
Why do these glitches exist? Several reasons:
-
My own limited perspective as a developer: I've made certain design decisions and have grown accustomed to the program working in the way I designed it, and no one has ever provided an alternative perspective. For instance, no one has ever complained about the double-click vs. single-click issue before. But, as this user noted, iTunes switches table views with a single-click in the tree display, and my program should too. Once I gave this idea some thought, it was obvious, and not very difficult to implement, but it took another perspective to get me to see it.
-
A sense of "if it ain't broke, don't fix it." PortAuthority was originally designed to be a simple graphical interface to the MacPorts command-line infrastructure: it simply piped commands to MacPorts and displayed the data that MacPorts returned. As the program evolved, however, I began adding more capabilities: for instance, MacPorts provides no mechanism in itself to filter ports by categories, but PortAuthority does. In adding these capabilities, I tried to do so in a conservative way by building on the way PortAuthority already worked: by fetching all my data from MacPorts and then performing whatever transformations I needed to get it to display in the fashion I wanted. Unfortunately, this had the effect of slowing the program down. A user noted that PortAuthority might be faster and simpler to use if it didn't have to call out to MacPorts for everything it did; after investigating this further, I found that it is possible fetch complete data from MacPorts on PortAuthority's startup, cache the data, and extract needed information from the cache; this speeds up PortAuthority considerably, and greatly reduces the number of times I need to call MacPorts to update my data. The old method of calling to MacPorts for everything worked, but the new method of caching my data works better.
I'll be rolling these improvements into a new version of PortAuthority very soon. And, just as importantly, I'll be rolling these improvements into my other programs as well. What I've learned represents a fundamentally better, more sophisticated way of designing my programs: it will raise the bar on all my applications. And I have user feedback to thank for that.
Sat, 28 Jul 2007
PortAuthority 2.2
I've released version 2.2 of PortAuthority, my GUI for MacPorts. This release includes a significant update of the user interface, as well as improvements to the documentation--including an introduction to MacPorts itself. This is also the first release to use my automatic update system, which seems to be working smoothly. If you use MacPorts and are looking for a program that makes this complex system more easy to use, check out PortAuthority.
Things have been pretty quiet here for the past month, but that's mainly because I have been hard at work on updating my applications.
My current focus is a new update to PortAuthority, my GUI for MacPorts. This update started out as a minor refreshing of the UI, but has turned into a pretty significant overhaul.
The current interface of PortAuthority, shown below, works well enough, but it's a bit cluttered. The port categories, placed in the side tree view, are obscured by the table view of installed ports below them. The interface also makes use of two separate "split" views (placing data side by side); these data displays are very asymmetrical in their appearance, which makes getting information "at a glance" harder than it should be. The colors don't look quite right for a modern Mac application (the tree view's background is white, instead of the gentle light blue that you see in apps such as Mail). Finally, the UI makes use of several odd-looking controls (the buttons don't look like Mac toolbar buttons, the search field isn't rounded, and there is a thin black line around the table views).
These are the unavoidable limitations when you use a cross-plaform GUI toolkit, Tk. Out of the box, it may not look quite right on a given platform. This is especially true on the Mac, where interface conventions are more rigidly defined, and interface fashions tend to change more quickly; it's hard for a cross-platform toolkit to keep up.
All is not lost, however. The beauty of Tk--one of the main reasons I use it instead of a Mac-only toolkit--is that it is almost infinitely configurable. Tk itself provides just the bare bones of a graphical interface, but those basic elements can be configured in a vast number of ways--both visually, and in terms of their behavior. Furthermore, Tk's vast array of extension packages allow a developer to quickly snap together different components and assemble a sophisticated interface that very closely matches platform-specific conventions.
With that idea in mind, I have done a fair amount of work customizing some Tk components to be more Mac-like, and incorporating those into the new version of PortAuthority. A sneak peek is below:
This new version incorporates a number of changes, some subtle and some obvious. You'll probably notice the implementation of the standard Mac search field from Schelte Bron; the blue background in the tree view, with improved spacing between the items for better readability; a toolbar that blends in far better with Mac conventions than the old version; and a table view without the distracting black line. More generally, you should also see a simpler, cleaner layout--the separate list of installed packages is gone, integrated into the main table view.
Far more work has gone into this than it might seem. It's easy enough to change some basic properties of the layout; changing a background color from white to a specific shade of blue is a line of code. However, researching the standard colors is time-consuming. I've spent a fair amount of time at Apple's Human Interface Guidelines site, the Indie HIG wiki (for specific interface items not covered by Apple's guidelines), and the CocoaDev site, where a lot of Mac developers post code snippets and discuss interface strategies. Coming up with specific UI properties, testing them, soliciting feedback, and so on, is time-consuming.
And that's just time spent on the basics--finding colors, measuring pixel widths between tree items, and the like. Implementing Mac behavior when it is not provided out of the box by Tk is more complicated. The current standard Tk approach to creating toolbars is to arrange a row of buttons in a frame at the top of the window; that's what I did in the older screenshot above. The problem is, most Mac programs haven't used toolbars in this fashion since 2003. Now Apple provides specific code libraries to generate toolbars, which are not supported by Tk; modern Mac toolbars behave differently than buttons arranged in a frame, in that only the image and text of the toolbar element gets dark when pressed--not the entire button. So I had to create a Tk widget that emulates modern Mac toolbar behavior, using labels rather than buttons, changing images (from a light version to a dark one) when the mouse button is pressed, and using Tk's binding mechanism to execute commands when the button is pressed. This is what I love about Tk: its flexibility and configurability make many things possible, even easy.
Much of this work has gone into generic code libraries that I will be able to re-use in my other applications, as well; over the next few months, I anticipate releasing new versions of all of my programs, with a vastly-improved Mac-look-and-feel. I also plan to wrap some of my Mac-specific libraries into general open-source packages that other developers can use. However, a lot of PortAuthority-specific changes were required by this new interface, as well. I had to completely rewrite the mechanism that retrieves, arranges, and displays the list of installed and available MacPorts packages. MacPorts itself does not provide an integrated view of installed vs. available packages; in the past I was content to simply display the output of each MacPorts command ("port installed" and "port list") in a separate table. However, part of the value of a graphical program such as PortAuthority is that it makes using the "under-the-hood" command-line tools simpler, easier, and more intuitive. PortAuthority provides a more high-level, comprehensive view of your MacPorts installation than the command line "port" tool (which runs MacPorts by default) can do.
I still have to do a bit more work with the new version of PortAuthority--some final testing, and updating the documentation singificantly. The new version should be ready to go in the next couple of weeks.
A final note: the work I'm doing represents an unqualified endorsement of Tk's future on OS X. There's still a bit of uncertainty here, because Tk's core developers on the Mac haven't yet publicly announced how they will address the impact of Apple's recent announcements about its programming frameworks on Tk. However, apparently a lot of issues are still covered by NDA (non-disclosure agreements) with Apple and I'm confident a roadmap will emerge after the release of Mac OS X Leopard is released this fall and NDA no longer applies. Barring some unforeseen disaster, I plan to stick with Tk, in both my Tcl and Python applications.
Looking at my laptop, I see a big mess: a lot of improvements to my programs are cooking. UI improvements. New features to make the programs more useful. And so on. But right now it's a big disordered mess, like a house that's being renovated. Time to get on the stick and start tying all these improvements together.
Well, after about a month of futzing around with alternative GUI toolkits, including RealBasic and Cocoa,I have come to the conclusion that my current framework--Tk--is the best one for me.
I've gotten enough reassurance from Tk's core developers that I am no longer concerned about its future on the Mac.
I'm a proficient-if-not-advanced Tk programmer, and it makes absolutely no sense to go back to ground zero and learn a new toolkit from scratch, so that I can rewrite my applications from scratch, so that they can do what they already do. I understand that the tectonic foundations of Tk are shifting deep below my feet, but I also trust that the developers of Tk-Aqua will be able to implement the necessary changes to keep Tk up-to-date on the Mac. After all, Tk has already transitioned from one operating system (Mac Classic) to another (Mac OS X), and one architecture (Mac PPC to Mac Intel) to another.
I realize this decision makes me a bit of an odd duck. I am aware of no other Mac-only software vendor who specializes in Tcl/Tk, nor am I aware of any other Tcl/Tk developer who targets the Mac only. That's fine with me. The Tcl/Tk community is a very supportive one, and provides plenty of tools and resources for developers to write great applications.
And for those of you who have been reading, thanks for your patience. I'll soon be releasing some great new updates to my applications.
Part of the reason for my reluctance to learn Cocoa to develop Mac applications is that it's radically different from what I'm used to. When I first started programming in 2003, I used AppleScript Studio for some small projects; this environment runs on top of Cocoa and uses Apple's developer tools, but it's really only suitable for basic applications. As a result, when I really began digging into programming and wanted to do more complicated things, I moved into languages like Tcl/Tk and Python. Significantly, I settled onto Tk as my GUI toolkit of choice, and I've spent the past three years or so developing expertise in that system.
What this means is that I've delved very deeply into a specific process of programming, with a particular mental model. I write GUI's all in code, by hand, using a text editor, and continually test them and refine them in code. Once the GUI is set up, then I define the processes that the GUI will run. If I need to lay out the GUI a certain way, I look at various extension packages to see what's available. In this fashion, I've developed a library of code, and a repertoire of techniques, that allow me to be productive. Adding a second programming language, such as Python, to my toolbox was relatively simple because I could map the particularities of Python onto what I already knew of Tk.
Cocoa doesn't fit into any of the mental models I already use. Even though I have a basic understanding of the standard Cocoa language, Objective-C, the Cocoa approach to programming is radically different from what I know. First of all, the development environment is more complicated. You use one program to create your interface (Interface Builder), and another to write code and manage your project (Xcode). This makes it harder to manage things, because you have to click so many buttons and navigate through so many windows.
Next, you don't have as much control over what you are doing. The GUI is laid out visually, not in code; you drag and drop things like buttons, text fields, and other widgets onto a window, spending a lot of time fiddling and getting them lined up just so. Then you name the methods/functions that these widgets will call, and draw connections between the various widgets (button A triggers a specific action, and then displays the data in text field B). After all that's done, then you write your code. Writing code is simple enough, but because the widgets can only be displayed in another application, it's easy to lose track of all the connections and actions and outlets.
I've followed this Cocoa tutorial and have also spent some time with an introduction to Objective-C programming. I understand the component parts--Objective-C isn't too different from other languages I've programmed in, and it's pretty cool laying out a nice-looking UI just by dragging stuff around--but so far the larger whole, the coherent mental model of what's going on, how each part fits, has eluded me.
I understand that some programmers find all the tools that Apple provides for Cocoa programming to be powerful and helpful, and not an impediment. But wading through all these windows and programs and connections, I feel a bit lost. And being lost isn't conducive to writing programs that you can sell.
I've been spending some time pondering the implications of Apple's surprise
announcement last week that there will be no 64-bit support for Carbon in Leopard.
Here's a web page with an overview of what is public knowledge:
http://www.carbondev.com/site/?page=64-bit+Carbon
I personally have no need for 64-bit performance in my apps. However,
from my (admittedly uninformed) perspective, it looks like the death
knell for Carbon. Even despite the continuing reliance of such major
vendors as Adobe and Microsoft on Carbon, it appears that Apple is
trying to forcibly move development to Cocoa. As such, I no longer have
confidence that Carbon will continue to be a stable and supported
platform for GUI development on the Mac, and I'm evaluating my options
in terms of the UI of my applications.
What's a Mac application? This is not just a rhetorical question. Mac users tend to be more passionate about their choice of computing platform than Windows users, in part because the Mac offers a distinctive and elegant user experience. So, it follows that a "Mac application" has some distinctive and elegant qualities--particularly features that can't be found on other platforms.
Some Mac users and developers are quite opinionated, and quite specific, about what makes a Mac application: it has to be written in Cocoa, Apple's Objective-C application framework. These developers represent the far extreme of the Cocoa enthusiasts, but they are by no means alone in their position. The dead giveaway is their hostility to Apple's Carbon framework: "Carbon is not a 'true' or 'good' OS interface: it's just a helper for 'legacy' MacOS code and was supposed to be fully abandoned once development teams got up to speed with Cocoa."
I have to disagree with their viewpoint here. A Mac application, at its most fundamental, is an application that takes advantage of Mac features. As I've said before, Cocoa provides access to those features--but so does Carbon. Via Carbon, my own applications take advantage of Apple's built-in help system; they hook into Apple's native print frameworks; they use dock badges, and other visual notification cues; and more. Additionally, I'm continually refining the user interface of my programs to bring them more in line with the prevailing, modern look-and-feel on OS X. My programs, though written with a cross-platform toolkit, would not run on another platform in their current state.
My programs, in other words, are Mac applications-- despite what the hardcore Cocoa enthusiasts say.
It's true that some aspects of my programs' interfaces don't hook into the standard Mac approach. My toolbars don't build on Carbon's toolbar components. My search field doesn't build on Carbon's search field components. That's a limit of the underlying GUI toolkit that I use (which is, incidentally, built on Carbon). So be it.
What's more important is that my applications work, and work well. They have good documentation, are easy to install, are easy to use, and have a responsive developer supporting them. They also integrate with Mac-specific features as much as possible. All of these aspects of my applications work together to afford a good user experience. And I'm always trying to improve that user experience; if a user has a suggestion that will improve the experience my programs provide, I implement those suggestions whenever possible. The main list of new things I'm adding to my programs right now are user suggestions.
What isn't in the cards, at least for the foreseeable future, is a rewrite of my applications in Cocoa or even a spiffier Carbon wrapper, such as RealBasic or wxPython. Oh, I've tried. I've downloaded countless tutorials, played with code samples, and even purchased some books and some software. But I never get very far. As soon as I start, I look at how different the other approaches are from my current approach, especially Cocoa, and my eyes glaze over. I look at the thousands of lines of code I've written over the past few years--functional, stable code that has gone through endless revision and refinement--and I wonder why I would consider rewriting all that code, just to gain some marginal improvements in the appearance of my programs. As a far more experienced developer than me once wrote: "When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years."
It isn't necessary to use Cocoa to write Mac applications. I'm a Mac developer, using Carbon. And I write Mac applications.
As I noted previously, I'm open to experimenting with new approaches to developing my applications. Toward that end, I spent the past couple of weeks playing with RealBasic, which is used by many independent Mac developers to develop their applications. At $100 for a Mac-only license, RealBasic was inexpensive enough that I was willing to give it a try. (RB has a two-week demo period, which I found to be insufficient.) RealBasic hooks into much more of the Mac out of the box than do Tcl/Tk or Python, my primary development languages. Plus, with a nice drag-and-drop utility for creating slick GUI's, I thought RB might be a good addition to my toolkit; it would help me build nicer-looking, more powerful applications, more quickly.
Unfortunately, I'm disappointed. RB doesn't feel like it's going to be a solution for me.
Some of this disappointment stems from my own learning curve, of course. I experienced this with Python at first, before getting my bearings in the new language, and then finally shipping a finished application in Python. RealBasic is very different from Tcl and Python. Getting proficiency would mean a period of months, most likely.
Still, in just a couple of weeks, I have bumped into some barriers that make RB a bad fit for my needs, or not worth investing more time in.
First, some of the GUI's I built proved unexpectedly ugly. The images in toolbar icons didn't display correctly--it turns out I need to install a free third-party plug-in that supports my image format (png). Why does a commercial IDE lack this (pardon the pun) basic functionality?
Second, despite what RealBasic's promotional materials say, my development time didn't seem to be reduced much. Throwing together a GUI is faster, but everything else is slower, because you have to compile everything. I learn a programming language best by playing around with it, and trying different things; such an approach is very feasible with a scripting language, where code is executed by an interpreter. You don't have to wait for things to compile. Unfortunately, that's not the case with RealBasic. Worse, even if I'm willing to accept the additional time required by compiling, the $100 version of RB doesn't let you build real command-line (console applications)--I'd have to spend an additional $400 to get the Professional version! (Console applications are easier for learning the basics of a programming language itself, because you are not adding the overhead of graphical components.)
Third, the biggest disadvantage of my current programming environment--its lack of full Mac polish in the GUI components--is rapidly going away. After posting some questions to a Tcl/Tk mailing list about how to render a certain GUI item in a Mac-like style--the standard search toolbar--someone posted a coding solution that solved the problem. Another recurring complaint about the "look" of my applications, their lack of a Cocoa-style toolbar, is also easily solved, it turns out; a bit of coding on my part has produced some samples that work quite well, so it won't be too hard to integrate this into my programs, and I will in turn share this code with others under an open-source license. Scripting languages, in general, have large, supportive communities that make it easy to find freely reusable components for that programming language; RealBasic, by contrast, has less of this kind of code and more proprietary extensions that require additional cash outlays.
Fourth, the kinds of applications I still have on the drawing board aren't really feasible in RealBasic. One of the applications, a file-transfer program, will be simple to do in Python. Achieving similar functionality in RealBasic would require the purchase of expensive additional components, and even those components wouldn't fully implement what I need.
Finally, RealBasic would be much harder to integrate into my current development frameworks. I have a very large library of Tcl code that manages various utility functions of my applications, such as checking for new versions. Adding Python as a development language wasn't easy, but it was worth the effort because Python's Tk GUI bindings allow me to call my Tcl code without modification. This wouldn't be feasible in RealBasic.
There's no doubt that my three years of development experience with scripting languages--particularly Tcl--have given me a strong bias in favor of that approach. It works for me. At this point, since I am an independent developer and have the luxury of choosing my own tools, that's my criteria: any tool I choose has to work for me, and has to work with what I already use. That's why, despite the difficulty and frustration of learning even a rudimentary amount of C--the lower-level language that Tcl itself is built with--this was helpful to my work, because it allowed me to code a extension to Tcl that accesses Apple's Help system. RealBasic, however, doesn't integrate smoothly with what I already do. (Neither, for that matter, does Cocoa/Objective-C.) So, at this point, I'm going to stick with what works for me. In this sense, I consider my experiment with RealBasic to be a success.
I had a lot of good responses to my blog entry about my first year as an independent Mac developer. I received numerous e-mails, was interviewed on the YourMacLife online radio program, and had comments from other bloggers.
What was especially interesting was the response from the Mac Software Business mailing list. A few of the folks there were encouraging, but many of the developers there were not. Specifically, they dismissed my work as "ugly" because I don't develop in their framework of choice, Cocoa. Instead, I develop in Tcl/Tk and Python, with Python's Tk bindings. "Your interfaces look wrong. You don't use native toolbars. You don't use native search fields. The applications look clunky. How can you sell anything?" Phew. "Learn Cocoa," they said. "It's the best way to develop on OS X."
Well, yes and no. A lot of independent Mac developers use Cocoa, and it's also true that this is Apple's recommended approach. However, there are Mac developers who also use Apple's Carbon frameworks, either directly via Apple's Xcode environment or through a higher-level wrapper such as RealBasic. (Non-Cocoa developers tend to be fairly quiet on the Mac SB list about their choice of frameworks; they often get shouted down by Cocoa developers, who are, shall we say, evangelical about their tools.)
I've written about my choice of programming languages and frameworks before, and why I've opted not to develop in Cocoa up until now. It has basically been a business decision: up until now, I've decided that I can achieve more revenue by putting my applications out there in their present form, and continuing to enhance them, than I could by doing a major rewrite of them in another toolkit. End users can't purchase a program that isn't released.
Of course, it's necessary to occasionally revisit your business strategy. You always want to make sure you are in tune with what your customers want. Are my end users clamoring for Cocoa applications, or at least more fully Aqua-specific, without emulation of certain things like the search field? That's something I'd find much harder to disregard. Unfortunately, my customer feedback on this question is mixed. I've had some users complain about the "look" of my programs; I've also had some complain that certain features/functions are missing. On the other hand, I've also had compliments about my programs, from paying customers. And sales of my programs, such as PortAuthority, have improved as I've added new features and enhanced the interface of my programs with new icons--updates that greatly improve the program without requiring a complete rewrite.
So the evidence is, at this point, inconclusive.
I can say that, as year two progresses, I will begin exploring some different approaches. This is also necessary. There's a lot I can accomplish with my current setup, and some things that I can't. My experiments with some different approaches to application development may find their way into my product mix; these experiments may also convince me that my current approach is sound. In any event, I'm looking forward to it.
One year as an indie Mac developer: What I've learned
In February 2006, I released my first commercial program, a precursor to NameFind. It was a failure, selling exactly one copy, but after taking a few months to regroup, I tried again with a commercial release of PortAuthority. PortAuthority had been under development for two years as an open-source project, had a large user base, and was a better candidate to use as the foundation for building a business. Since then, I've released four more programs, including a significant revamp of NameFind, and have watched my overall sales grow steadily.
I haven't gotten rich from software development. In fact, the income I've earned so far might qualify as a nice supplement to my main income, but isn't yet enough to provide my living. However, by at least one measure--"only the lucky/smart few make >$100 per month"--my software business qualifies as a success, albeit a modest one. In that light, I'd like to share a few insights that have helped the growth of my business.
Focus on Mac-only development. Part of the problem with the first iteration of NameFind was that I
had released it as a cross-platform application, supporting it on Linux
and Windows as well as the Mac. Bad move. It was criticized on a Mac
download site as "a primitive Windows port." It worked fine
on Linux, but Linux users generally don't pay for software utilities,
which are freely abundant through their package manager; there's no
way I can compete with "apt-get install foo." And while the
program did sell a bit on Windows, I'm not a Windows expert. Deciding to concentrate on Mac-only development isn't a silver bullet,
but it has allowed me to bring a sharper focus to what I do. For one
thing, it simplifies the amount of coding and testing I have to do;
in turn, I can concentrate on optimizing my software to the platform
that I know best. Mac users have very high expectations for their software
in terms of its user experience, and I can best meet those expectations
by focusing more deeply on the Mac.In fact, I began to notice an increase in sales of my software when
I ripped out all the non-Mac code in my programs, purchased some Mac-themed
icons for my applications, and re-designed
their interfaces to better reflect best practices on the Mac. Use technologies that you are most productive in. When I first started programming in 2004, I chose languages that would
allow me to get stuff done right away: this specifically meant Apple's
AppleScript Studio environment, which allows you to build Cocoa applications
in AppleScript. I did a few small projects in AppleScript, which was
very useful as a learning experience, but AppleScript itself is a pretty
limited language, and couldn't do some of the things I wanted to try.
At that point my alternative was to move towards learning Objective-C,
Cocoa's native language, or try another higher-level language like AppleScript,
but one with more capabilities. At the time, the learning curve for
Objective-C looked too steep, so I decided to focus instead on Tcl and
Python. These languages provide most of the power of Objective-C--and
far more power than AppleScript--yet are easier to learn. As a result,
I became productive in them fairly quickly, and have been developing
in them ever since. (I discuss my choice of languages in more depth
here.) I'm a bit unusual among indie Mac developers in using scripting languages
as my tool of choice; most other developers use Cocoa/Objective-C, with
some using RealBasic or Java. But my use of scripting languages is,
for me, a competitive advantage; I can get busy writing applications,
rather than slogging through months of learning the basics. Many developers
praise Cocoa/Objective-C as a high-level development framework that
lets you build applications faster and more simply than competing environments:
perhaps that's true if you're using old-style Mac development, or standard
Windows development, as your basis for comparison. But I guarantee you
there's no way I'd have five applications released if I were doing them
in Cocoa/Objective-C. End users don't care about your choice of technology; they care if
your program solves their problem. The religious battles fought between
developers over frameworks, programming languages, and so on, mean little
to the average end user. What's most important, instead, is paying attention
to user expectations in terms of application functionality, look-and-feel,
and so on. Careful attention to the Apple HIG is possible in any language
and toolkit. My point here is that if you are already productive in Java or RealBasic
or another language, you are probably better served by developing your
application in your language of choice, rather than going back to ground
zero and learning Cocoa. You'll have your application out for sale that
much sooner. Find a niche with a problem that needs solving, and deliver a
clean, polished application to solve that problem. This point seems obvious, but it's actually the hardest one to achieve.
Finding a niche is difficult. There are a lot of applications out there,
and a lot of crowded market niches. Does the Mac world really need another
RSS reader, another system cache cleaner, another Spotlight enhancer?
Doing something useful in any of these categories, that will actually
persuade people to part with some cash to purchase your application,
is very difficult. If you can find a space for yourself where there
is little competition, but some market need, then you will be successful.
My own applications are proof of this point. My best-selling application,
PortAuthority, has its market niche pretty much to itself right now,
and it filled a real need when I first released it. My poorest-selling
application, NameFind, competes in a massively crowded niche--Spotlight
enhancers/replacements--and it's hard to find a unique place in that
niche. My other programs--Phynchronicity, PacketStream and VuMan--fall
somewhere in between. You're more likely to be successful if you write a program in response
to market need, rather than writing a program to scratch an itch or
play with cool technology. "Scratching an itch" can be useful
as a starting point, or for learning purposes, but it's not likely to
be the basis of a long-term, successful business. Don't be afraid to charge what your product is worth. Again, this may seem obvious, but for me this was a hard thing to grasp.
I started out as a freeware/open-source developer; I wrote software
for fun, and to learn. It wasn't until I achieved a certain level of
proficiency, and had a program in widespread use, that I thought I might
be able to earn some income from software development. But I had some
questions to answer: Is it right to charge for software? Would users
of my formerly free program actually pay for a new version? What price
should I charge? I went through all sorts of contortions and changes
in direction before finally settling where I am today: charging $20
for my stuff, which seems a fair price given most of the market niches
I target, and which provides me with an adequate level of compensation. Don't put all your eggs in one basket. I have five programs currently for sale, with more on the drawing board.
Of those five, one (PortAuthority) provides the majority of my income,
but all of them contribute something, and some of them have not begun
to grow in the way I think they can. The point of having multiple products
is to mitigate the risk of any one program heading south. It also means
that you can achieve success by having a number of programs that sell
modestly. Not every application can be a huge seller--in fact, most
applications are not huge sellers. Pay attention to marketing. Don't just put out an application on a website and hope that people
download it. You need to put some effort into marketing. Fortunately,
the Mac market has a rich marketing ecosystem--an interconnected group
of download sites, news sites, and so on, which makes reaching potential
users of your software relatively easy and inexpensive. My marketing
program consists of posting downloads of my software to VersionTracker,
MacUpdate, and Apple;
sending news releases to MacNN, MacMinute
and PRMac; and sending announcements
to mailing lists. This pulls a lot of traffic to my website, and I usually
see a huge spike in downloads--and, not too long afterwards, sales.
The best part is, it doesn't cost me a dime to do any of this. These are some of the strategies that have guided my growth as a commercial software developer. Actually building a software business--even the modest one I've developed thus far--is several orders of magnitude more complex than simply writing code. But it's a great pleasure to earn part of my living writing software, and it's an honor every time someone parts with a few dollars because my software has helped to solve their problem.
A large number of updates today, but nothing sexy: all of my applications now have a mechanism for downloading updates. Also, each new version re-sets the demo period for 30 days. So, if you've tried any of my programs in the past, you're no longer locked out of demoing a new version. See http://www.codebykevin.com for links to each program.
I'm pleased to announce the release of PortAuthority 2.0, my GUI for MacPorts. This is a major update, featuring a complete redesign of the GUI, new icons, and bug fixes. I've raised the price to $20 to bring it in line with my other programs, and have eliminated the upgrade discount for users of the freeware/cheapware version from SourceForge and Lulu.com. It is, however, a free update to registered users. If you use MacPorts, give it a try.
Many software developers find themselves gravitating to a specific market niche: in other words, their software focuses on a narrow set of related problems. In my case, I develop graphical interfaces for Unix-based command-line tools. In most instances, the Unix programs themselves are free and open-source. In many instances, my own programs compete with applications that also provide a GUI for these command-line tools; the other GUI programs may themselves be free and open-source as well. My programs, of course, are closed-source (proprietary) and cost money to license for full use.
I've seen some grumbling about my approach among open-source developers. They seem to think that all software should be free and open-source. In fact, I've seen more than one programmer vow to write a free application that competes with one of my own; it seems they want to put me out of business. Some actually claim my approach is unethical--as if charging money for software was morally wrong.
When I was first learning software development, I was something of an open-source zealot: I didn't understand why anyone would want to keep the code of their software closed, or demand payment for it. It wasn't until I had been programming for a few years that I decided to turn it into a business; I have a family to feed, and I wanted something that I invested so much time in to help support my family. After experimenting with a few different approaches, I settled on a traditional shareware model. I'm pleased with this approach and will continue with it.
There's nothing morally wrong with charging money for the software I develop. My software runs on top of free/open-source tools; I'm not lifting code from these programs in violation of their license. Many, many end users feel that my software provides a useful benefit to them; that's the entire purpose. I can definitely say that earning part of my living from software develoment is the best guarantee that my programs will continue to be developed and improved. I can't say that for many of the free/open-source programs I have developed. Without a financial incentive, it's easy to abandon a project once you lose interest in it. I noted previously that one popular open-source program that I compete against has barely been updated in four years. That's certainly not the case of any commercial program I develop.
So, to any and all free/open-source developers who want to write software that competes with mine: welcome to the market. If you create a compelling and useful program, good for you. If you stay over the long term and continue to develop it, more power to you. End users certainly benefit the most from having a variety of choices. But I'm not going anywhere, and I will also continue to develop and improve my programs.
After several months of development, I've released Phynchronicity, a GUI for the Fink package management system for OS X.
Phynchronicity is similar to another application I develop, PortAuthority: it aims to provide an easy-to-use graphical interface to command-line tools for installing Unix software, which can be intimidating for many users. (In the case of PortAuthority, the software management system is MacPorts.)
The main difference between Phynchronicity and PortAuthority is that Phynchronicity is competing against a long-established, polished, and free application: FinkCommander. (PortAuthority, at present, pretty much has the MacPorts GUI field to itself.) When I first started delving into the world of Unix software four years ago, FinkCommander and Fink were among the first things I installed. FinkCommander, in fact, was the inspiration for early versions of PortAuthority.
As time went on, however, I found myself growing increasingly impatient with FinkCommander. It doesn't quite do enough to simplify Fink, in my view. Instead, it presents the user with an almost overhelming array of options. For instance, you can install software from source code, or from pre-compiled binary packages. Its slim (and old) documentation doesn't explain which approach is better (although you can delve into the Fink documents itself to figure this out). It provides too many different ways to update the Fink infrastructure itself. Browsing and searching the Fink database is somewhat difficult with FinkCommander. Finally, FinkCommander is something of an orphan: development on it pretty much stopped in 2003, with only a few bug fixes since then, and a release update as a universal binary that added no new features.
So, I felt there was room to improve on FinkCommander. I designed Phynchronicity with the familiar three-pane interface that is so popular with e-mail programs, newsreaders, and so on; this make browsing Fink packages much more intuitive. I've also deliberately minimized the number of options for the end user; in fact, Phynchronicity currently has no user preferences at all. (This will be phased in over future releases.) And finally, I've tried to install a basic documentation package that will grow and evolve with each new release of Phynchronicity.
So, there you go: if you want to try an alternative to FinkCommander, now you have one. I'm eager to hear what you think.
Phynchronicity 1.0 in the works
I'm taking a break from my update of PortAuthority to wrap up version 1.0 of Phynchronicity, a GUI for the Fink Unix software management system.
Phynchronicity is an important project for me in many respects. Most importantly, it's my attempt to apply the same design approach that I used with PortAuthority--which is a GUI for the MacPorts Unix software management system--
Here's a screenshot of Phynchronicity:
Phynchronicity is also important for me because it's written in Python. As I've written before, I've had some difficulty with Python, especially with creating a GUI that is more than moderately complex. However, coming back to it with a fresh set of eyes has allowed me to work through some of the issues I previously had. My difficulties were the result of my own lack of learning, rather than bugs in the language or its libraries.
So version 1.0 of Phynchronicity, written in Python and featuring a GUI as sophisticated as anything I would develop in my other programming language, Tcl, is due shortly. The first release will have a limited set of features; my emphasis is getting the basic design of the program (both in the user interface and under-the-hood) in place. Working from a stable foundation will allow me to add new features quickly.
Fri, 23 Mar 2007After releasing new versions of NameFind, VuMan, and PacketStream, I'm now embarking on an update and redesign of PortAuthority.
PortAuthority was the first substantial application I developed, and while it has evolved and undergone refinements since I released version 0.1 in 2004, its basic feature set has been stable for the past couple of years. That means I've modified portions of it without looking at the way it's structured as a whole. Now, I'm taking another look at the entire codebase, with an eye toward doing a more substantial redesign and overhaul (not just changing icons or otherwise updating the look, though that's part of it).
All I can say is, Yikes. I've learned a lot since I first started working on PortAuthority, and while I've applied those smarts to my more recent programs, they haven't found their way to PortAuthority.
For instance: sometime over the past few months, I developed a little Tcl library that popped up a password dialog box, and then returned the password data to execute a command with root privileges. I got tired of cutting and pasting this kind of code from one application to another; it's the kind of thing that, with a little work, can be made generic and thus usable in any application.
Integrating this library into PortAuthority has eliminated about 500 lines of code. Over the years, I have added near-duplicate-but-slightly-different code snippets to pop up separate dialog boxes for five or six separate commands. That's dumb. Redundant. A waste of time.
Cleaning out this cruft is necessary. It's not the same as rewriting an application from scratch; it's cleanup. The visible result to end users of PortAuthority will be a nicer-looking application; the result for me will be an application that is easier to maintain and update.
Mon, 19 Mar 2007Over the weekend, I ran across a nice article on Mac desktop search programs, which included discussion of NameFind. The review wasn't entirely positive: the writer said NameFind worked well, but felt it was overpriced in comparison to the other programs.
I'm not upset by the criticisms. In fact, I'm grateful that the writer paid attention to NameFind; to me, this validates NameFind as a worthy entrant into the field of Mac search utilities. My challenge is to continue improving the program enough so that its value reflects the price I'm asking for it. And I have plenty of ideas on how to do that. Stay tuned.
Wed, 14 Mar 2007I've released version 2.0 of NameFind today. The new version includes a significantly nicer UI, streamlined search, and bug fixes. If you don't like Spotlight, give NameFind a try.
Tue, 13 Mar 2007Well, there's nothin' like a little egg on my face. :-(
After announcing that I wouldn't use Python in my development, guess what:
I find that I need Python.
Specifically, I am going to develop my next new application, Phynchronicity, in Python.
After my difficulties with Python before, why change now? Because of a more fundamental principle of software development: it's better to clean up old code than to scrap it.
Before I ran into my showstopper difficulties with Python and PacketStream, I spent a fair amount of time prototyping Phynchronicity in Python/Tkinter. The GUI, while a bit rough, was well on its way to being complete, and polished. I had little doubt about Python's "under-the-hood" ability to meet my needs here: I was mainly worried about the limitations of using Python's bindings to Tk, my GUI tooolkit of choice.
Those limitations are real--for various reasons, it's very hard to do certain things in Python that are easy to do in Tcl/Tk, and in such situations make Python is a poor choice for developing a GUI via Tk. But limitations can be worked around, with intelligent decisions in interface design.
So, this means I've been putting together a Python/Tkinter GUI in a slightly different fashion than I would a Tcl/Tk GUI. It might be a little simpler in appearance. But it won't be any less feature-rich--and it will be clean and attractive.
Besides, Python is a fun language to develop in. It has some cool features that Tcl lacks. The difficulties I had with the Python version of PacketStream--and the existence of a nearly-finished Tcl prototype--made it simpler to switch to Tcl rather than work through whatever bugs existed in the Python version. In the case of Phynchronicity, however, starting with Tcl means starting from scratch. And I'm not eager to do that. Since I've already invested a lot of time in the Python version, it's easier to continue with Python. So that's what I will do.
Thu, 08 Mar 2007I've been working on my list of forthcoming program releases, and I've learned something: it's better to keep the features for each new version limited--or perhaps focused is a better word--so that I can have a manageable process for getting the new version done.
The problem is that I usually have more ideas than time. It's not hard to find cool new things to add to programs. For instance, NameFind is due for a UI makeover to make it more polished and Mac-native. An extensive re-design of the GUI, without extensive new functionality, is a big job in itself. And simply integrating basic improvements that I'm adding to all of my programs (such as a nicer-looking password dialog) involves modifying and/or ripping out a lot of redundant code.
But I still have lots of new ideas! I've figured out how to get Mac-native icons displaying in my programs, for instance; this was tricky, because Tcl/Tk doesn't support this out of the box. I want to integrate this into NameFind. And I want to change the way the program notifies users when a search is complete, from Growl to a bouncing dock icon. And, at a more basic level, I want to offer more options for searching your system for specific files. That last idea could involve a major re-write--or a major expansion--of NameFind's core code.
So, how do I proceed? Adding all of this stuff at once would take months. It would make NameFind a really cool application, but until it's released, no one could try it (or buy it). That might be fine if the current version were selling like hotcakes, but, well, it's not. I see getting at least some of these improvements out soon as the key to helping to jump-start sales.
So, I've decided to take an incremental approach. The GUI redesign is the major new feature that will be included in version 2.0 of NameFind; that, and some under-the-hood improvements that I've been making to speed up the search process. This will allow users to benefit from a dramatically better-looking, faster, and (hopefully) easier-to-use application. The other ideas will be phased in, gradually.
And this approach--phasing in ideas gradually--is turning into the approach I'm going to use for all of my programs. By limiting the scope of each new release to just a couple of ideas, it will make it easier for me to code the ideas, test them, and make sure they are rock-solid. Huge updates are much more difficult to test, take longer to code, and are more prone to bugs.
Fri, 23 Feb 2007I've released new versions of PacketStream and VuMan. These releases are the first public result of my efforts to upgrade the UI of my programs.
I've raised the prices slightly, to $20, in recognition of the increased value I think the new UI provides. These are free upgrades to registered users of the programs (those who purchased a serial number).
Thu, 22 Feb 2007...to Mac developer Daniel Jalkut, who has acquired one of the leading Mac applications for blog authoring, MarsEdit.
Daniel is a well-known blogger among Mac developers, and has developed several interesting desktop applications for Mac users. But MarsEdit is on a different level of prominence than the programs Daniel has developed himself, and should drive substantial growth for his software business.
I posted a comment on Daniel's blog saying that growth through acquisition is especially unusual among solo developers, for no other reason than the substantial capital investment it requires. But if any product represents a safe bet, it's MarsEdit, which was first developed by Brent Simmons and became part of NewsGator after NewsGator purchased Brent Simmons' company. And Daniel is an extremely skilled developer: it's safe to assume that he will be adding a lot of cool features to MarsEdit, making it even better than ever.
Congratulations, Daniel!
Wed, 21 Feb 2007I'm working on major updates to all four of my currently-released applications. These updates focus less on adding lots of new features and more on giving the user interface of each program a major makeover, to make them more intuitive and simple to use.
What this means is going beyond simply trying to make the interfaces polished; it means trying to integrate as much standard Mac behavior and appearance as possible.
Toward that end, I've purchased a set of commercial Mac-style icons, to replace the open-source icons I've been using. I've also dug deeply into Apple's interface guidelines (and looked at a lot of popular Mac applications) to see what I can do to improve the interfaces of my programs.
Here's a sample of how I'm doing the makeover for VuMan, my man page viewer.
First, the current version, 1.3 (click on the image to get a larger view):
This version uses icons from the open-source Tango icon project. The Tango icons are most popular on the Linux operating system. While not unattractive, they are not entirely consistent with the Mac-Aqua icon style, which tends more toward photo-realism. Also, these icons are based on GIF files, which is Tk's native image format. Thus, they are a bit jaggy.
Other points about the current interface of VuMan: it uses a Mac-native combobox to select categories of man pages, but in a manner not entirely consistent with best Mac interface practices; it also uses a basic search field, not the Mac-native one (look at Safari or the Finder to see what I'm talking about), because my programming environment, Tcl/Tk, does not have built-in support for this interface element. Finally, the list of available man pages is displayed on the right, in a layout that attempts to simulate the Mac-style "drawer." (One of the toolbar buttons closes the "drawer.")
The overall effect of the interface of VuMan as currently released is, in my view, "usable, but not as Mac-native as it should be, and a bit unpolished."
Now, here's the revised version (still in progress):
The new version uses Mac-style toolbar icons. These are modelled after the icons that ship with OS X, although they are not the actual system icons; I purchased these from an icon designer. I think the new icons, by themselves, help the application to feel more Mac-like. I have also implemented the menubutton icon with the "gear" image that is showing up on more and more Mac applications, such as Mail.app; I use that to select the category of man page that is displayed. The new interface also implements a Mac-style search field; it uses a Mac-style search icon, and keeps a history of search terms. (I found some open-source Tcl/Tk code that implemented the basic search field, and I modified it to look more Mac-like.) Finally, the new interface is less "cluttered" than the old one; it places the list of man pages in a separate pane of the main window, where it can be easily accessed.
All of the programs I develop are getting this kind of makeover; there will be certain common elements that I incorporate into each application, such as the new search field, but there will also be design updates specific to each program, based on user feedback.
What's the point of all this work? Foremost, to increase sales. I believe that the more intuitive and "Mac-like" an application is, the more likely a user is to purchase it; the user can more easily evaluate the program's features without being distracted by the sense that things aren't quite "right" in terms of its look and feel. My own test for this is that the first time I launched VuMan with the new look, I forgot I was looking at a program I developed; it felt like just another Mac program. That's progress.
There's been a lot of blog buzz among Mac developers about Daniel Jalkut's interesting suggestion about programming languages--that an increasing number of Mac desktop programs will be written in scripting languages like Python and Ruby, with developers using lower-level compiled languages like C and Objective-C only for specific, performance-critical parts. Apple itself is promoting this trend by including Cocoa bindings for Python and Ruby in the next version of OS X, Leopard.
All I can say is: Welcome to the revolution, guys.
Context: Much commercial Mac programming is done in Objective-C, which is the basis of Apple's flagship Cocoa programming environment. A large number of commercial applications that date back to the old Classic MacOS days are programmed in C or C++ using Apple's Carbon frameworks. Compiled languages such as C, C++ or Objective-C produce software that is fast and powerful. But programming in such languages is a slow and complex process, because developers must manage many low-level details such as how their code interacts with computer memory; also, whenever a change is made to code, a programmer must recompile the program to test the change, which (in the case of a large program such as Microsoft Office) can take hours.
Scripting languages differ from compiled languages in a significant way: they do not require compiling. Instead, code in such languages is executed by an interpreter (which is usually itself written in a compiled language such as C). Scripting languages are called "higher-level languages" because they take care of many low-level details for the programmer, such as memory management; they also have many built-in libraries for managing data that compiled languages lack. The benefits of using scripting languages include faster development time (because programs do no need to be recompiled for testing, and because the scripting language has more built-in power); and a simpler learning curve, because some complexity is managed by the language itself. The drawbacks include slower programs in some cases; and more accessible source code, since the code itself is not compiled.
(This article provides a useful summary on the benefits and drawbacks of scripting languages.)
If you've read this blog before, you know that I am a huge advocate of scripting languages. All of my programs are written in Tcl/Tk. While not as trendy as Ruby or Python, Tcl is just as powerful, and its Tk GUI bindings (built on top of Carbon rather than Cocoa, as Tk was ported to the Mac OS a decade ago) allow the creation of sophisticated GUI's. I chose Tcl as my main development language for the reasons outlined above: its power required only a modest learning curve. I have learned a rudimentary amount of C--enough to code a small extension to Tcl to add functionality that was not built-in to the language--but otherwise I spend nearly all my time in Tcl. I'm extremely productive in that langauge, while sacrificing very little--if anything--that programmers in C or Objective-C have.
So, again, I say to all you scripting language converts: Welcome.
Mon, 29 Jan 2007I must update my previous entry about the limitations of Python and Tkinter as a programming environment. I'm not just going to limit my future work with Python. I've decided to chuck it altogether.
Although downloads of PacketStream--which is written in Python--have been pretty good, it hasn't sold any copies yet. While sales of any brand-new product are often slow, some users have reported problems--as in, PacketStream doesn't work. They press the buttons they are supposed to press and nothing happens. That's definitely a problem.
Unfortunately, I couldn't reproduce the problem, let alone figure out how to fix it--until tonight.
I decided to go ahead and start adding a big new feature to PacketStream--one that lets you filter the network traffic you monitor to a specific port. For example, if you just want to monitor web traffic, then you can set the port to 80, the standard http network port. This feature will make PacketStream more useful in looking at specific types of network traffic.
So I got the code written for the new features, started PacketStream, pressed the button I am supposed to press, and nothing happened--just like other users have reported.
Needless to say, I found myself becoming frustrated. I tried all sorts of variations to get the program working, or at least isolate the problem, but nothing worked. PacketStream just sat there, chugging away, but not outputting any data or any error messages, either.
Finally, out of desperation, I dusted off the old prototype of PacketStream that I wrote last fall in Tcl, my main programming language. I made the same tweaks to the old prototype that I did to the Python version of PacketStream, started the program, and pressed the button.
Bingo. Beautiful network data flowing across PacketStream's main window.
Python version: doesn't work. Tcl version: works.
I'm baffled as to why one version works and the other one doesn't; both make use of similar programming techniques (specifically, opening a pipe to the external network monitoring process and reading the data in a non-buffered mode, then writing the data to the text display). The only difference I'm aware of is that the Python version uses threads--a progarmming method that runs processes in parallel--and the Tcl version doesn't. Perhaps it's some subtle bug with threading that is causing the problem; threading can be complicated, I'm told, and I'm not an expert with threads.
But I don't really care what the problem with the Python version is. I don't need to care: I have a functioning Tcl prototype that already works better than the commercially-released Python version.
Guess what version 1.1 of PacketStream will look like? Hint: It won't be written in Python.
Mind you, this is surely more a reflection on my reasonably high level of proficiency in Tcl (and lack of same in Python) than a verdict on the merits of Tcl vs. Python as languages. Nonetheless, this is the final straw in my frustration with Python. I'm going to stick with Tcl from now on, period. And that means going back and releasing PacketStream as a Tcl application.
In most cases, rewriting an application from scratch is not recommended; in fact, some programmers say it's the worst mistake a software company can make. There's definitely wisdom in that. However, in my case, the Python version of PacketStream was actually the rewrite. The prototype was done in Tcl. In re-writing PacketStream in Python, I mapped what I had already done in Tcl--what I already knew about the program's design and structures--into a different programming language.
Well, enough of that. I can do everything that I need to do, and then some, in Tcl. It will take very little time to get the Tcl version of PacketStream up to release quality. And I'm not looking back after that.
Sat, 27 Jan 2007I think I've reached a moment of truth in my use of Python for programming: its Tkinter GUI toolkit is simply too limited for rich GUI's.
As I noted before, Python itself is a very rich, very powerful language, but it's harder to use its Tk GUI bindings than from Tk's native language, Tcl. I've done work in trying to integrate Tkinter better with some cool Tk libraries that allow more sophisticated GUI's.
Nonetheless, things aren't working the way I would like. I keep running into various bugs of one sort or another, in which things don't work under Python the way they would work under Tcl, and these bugs are beyond my ability to fix.
One example: I want to use Python's bindings to the BWidget Tk library, which allows for richer GUI's than the base Tk widgets (BWidgets provides a tree widget, drag and drop, listboxes with images, and so on). But I can't get things to work quite right: no matter what I do, I can't figure out how to get selected text to display properly. This bug report went unanswered, which means I'm pretty much on my own here.
This means I have a couple of choices if I want to develop an application with a GUI more sophisticated than PacketStream's; I can use Python with another GUI toolkit, such as wxPython, or I can use Tcl as the development language.
Given my investment in Tcl, and my reluctance to spend yet more time learning another GUI toolkit, I think this decision is pretty easy.
I'll certainly continue to develop PacketStream in Python, and there may be instances where Python is an attractive option and the requirements of a GUI do not exceed what Python/Tkinter can deliver. But absent that, I will be concentrating more of my development time on Tcl.
Fri, 05 Jan 2007The biggest milestone today is the release of version 1.0 of PacketStream, a network monitoring application. (It's a GUI that wraps the Mac's built-in tcpdump command-line tool for monitoring network traffic.) I've written a bit about the development of this application from a technical perspective. I'd like now to talk about some of the business reasons for developing this program.
A few years, I noticed a huge spike in traffic on my server: instead of blinking, the little traffic lights on my AirPort base station were solid white. I wanted to find out what was causing the traffic, but I wasn't sure how. A bit of Googling showed me that my Mac had a command-line program called tcpdump that could display what was coming in over the network. I tried tcpdump, and got it working, sort of, but it was hard to use.
I wondered if a GUI tool was available. A little more Googling turned up a program called MacSniffer, which is a GUI for tcpdump. I downloaded the beta version (the developer had suspended the $15 registration fee) and gave it a try. It made navigating the network traffic a lot easier, and I soon found that someone had hacked into my server and was using it to upload warez to a hidden directory. (FTP has never been open on my server since.)
MacSniffer, in short, is a great tool. But it hasn't been updated since I used it three years ago, and for whatever reason, it doesn't work on OS X 10.4, at least very well. And while there are other, free, Unix-based GUI's that can also display network traffic (I've even written launcher applications for these Unix tools), they are painful to install and use, and just aren't Mac-native.
Hence, PacketStream. It's as easy to use as MacSniffer, works well on OS X 10.4, and will have cool features added on a regular basis (that MacSniffer and the other programs out there lack). It's the network monitoring tool I've always wanted--and I hope you find it useful as well.
Today I've released updates for PortAuthority, VuMan, and NameFind.
The VuMan update is significant because it now supports native Mac OS X printing; thanks to Mats Bengtsson for his great work on the MacCarbonPrint library for Tcl/Tk, which allows native printing on Mac OS X. (Before, VuMan used the Mac's command-line lpr tool for printing.) I contributed a patch to the MacCarbonPrint code base that makes printing text a simpler process.
NameFind and PortAuthority have bug fixes and updates to the documentation.
Finally, I've raised the prices of VuMan and NameFind to bring them in line with PortAuthority.
Enjoy!