Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
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 2007
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 2007
Things 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 2007
After 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 2007
I'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
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: