About
Code by Kevin: Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.

Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Simplicity vs. power

A big part of my design philosophy as a Mac developer is to harness the underlying power of the Unix command-line tools that reside beneath the Mac's shiny Aqua surface. This means that I attempt to expose the functionality of these tools with an easy-to-use graphical interface. As I do this, however, I am often faced with a conflict between simplicity--making the tool intuitive to use through the GUI--and power--allowing the user to access as much of the tool's functionality as possible through the GUI.

That conflict is not an easy one to negotiate. If you don't expose enough of the program's functionality, you run the risk of "dumbing it down"--making it less useful than it should be. A GUI tool that provides only a simple wrapper to the tool's most basic functionality doesn't offer a lot of value to the user. On the other hand, if the GUI tool attempts to access every single command-line switch from the program, you run the risk of burying the user in an avalanche of configuration options and preference settings, and overwhelming all but the most advanced users--who many not need the convenience of a GUI tool at all.

Sometimes finding the right balance between simplicity and power is straightforward. In both PortAuthority and Phynchronicity, the command-line tools that power my applications offer a managable range of functions--installing, updating, deleting, searching, and getting information about Unix software--that can easily be encompassed in a GUI. In the case of both of these programs, the GUI itself handles some functions (especially searching the list of software packages) and dispatches other functions directly to the command-line tool as required. My programs offer a more pleasant user experience over the command-line tool without sacrificing any essential or advanced functionality.

In other cases it's harder to find the right balance between simplicity and power. This conflict is especially acute in my network monitoring tool, PacketStream. PacketStream is a user interface for tcpdump, an enormously powerful but complex network monitoring tool. The documentation for PacketStream outlines a stunning range of options, which, in the hands of a power user, results in the ability to monitor network traffic with incredible precision. It's hard for a GUI to capture all of that power without becoming equally complex to use. (Some GUI tools for tcpdump, such as WireShark, are unabashedly complicated to use.) The challenge for me is to identify the most common uses for tcpdump and provide access to a range of functions in PacketStream, without turning the program into something as complicated as tcpdump itself.

It's still a work in progress, and I've been guided by my own instincts and user input. The earliest version of PacketStream just provided a simple wrapper for tcpdump with no options beyond which network interface it listened to (Airport, Ethernet, etc.). Over the past couple of years, I've added the ability to listen on specific network ports for certain types of traffic (such as http, e-mail, etc.), and to display the contents of packets; these are command-line switches to tcpdump options. I've also added, at the GUI level, the ability to save and print network output, and to call PacketStream via AppleScript and the Mac Services menu. These aren't hooks into tcpdump itself, but they do make the program more integrated into the Mac's GUI environment, and allow it to cooperate with other programs. Finally, I've also added some basic documentation on tcpdump itself, to assist users in understanding how PacketStream works under the hood.

I've also removed some features, or at least moved them out of the GUI, in the interest of making the program simpler without sacrificing power. Adding Keychain support allows you to type a password once and then store the password in the system keychain: some users have complained about having to type a password everything they launch a search. I've also added functionality that automatically sets the correct network interface to listen on. In these cases there's a lot of code working to make the program more effortless to the user, with less configuration required; I've been able to increase the program's simplicity with no adverse effect on its power.

Certainly my design decisions with PacketStream aren't for everyone. One review of the program, undoubtedly by a power user of tcpdump, complained that PacketStream is too simple, little more than a worthless GUI wrapper for tcpdump's most basic functions. I don't agree with this assessment, as there is a considerable amount of work in PacketStream to make accessing tcpdump seem effortless, but there it's certainly true that PacketStream doesn't provide access to every feature of tcpdump. Nonetheless, PacketStream is one of my better-selling programs, so at least some users are finding that it provides a good mix of simplicity and power.

My long-term goal for PacketStream is to improve both its simplicity and its power, by making the interface more and more effortless to use, even as I gradually expose more of tcpdump's functionality. Making power seem effortless is the design philosophy of most good Mac software, and I will continue to move PacketStream--and all my other programs--in that direction.

[/general] permanent link

Packaging vs. developing, or mainstream vs. cutting-edge

As a developer primarily using scripting languages (Tcl/Tk and Python), I have multiple options for setting up my development environment: I can use the versions of the languages bundled with OS X; I can use one of several freely available binary installers for the languages; or I can build my own.

The drawback of using the bundled versions with OS X is that they tend to be out of date; Apple only updates its scripting languages with a new release of OS X. As a result, the version of Tcl/Tk available on my machine is 8.4, which is a couple of years out of date.

Binary installers--from ActiveState for Tcl and Python, or the official Python website--are very convenient, but you trade that convenience for control over your development environment. It's difficult to do non-standard or cutting-edge stuff with the standard pre-packaged distribution. My work with Tk-Cocoa and 64-bit, for instance, is too cutting-edge for these distributions; in fact, a lot of my work with Tk-Cocoa and extensions is being incorporated into the next generation of ActiveState's Tcl/Tk installer.

As a result, I'm left to the final option of the developer--"rolling my own," or building my own stuff from source. That's actually fine in most cases. I have complete control over my environment, and I'm able to focus on what I need to do. The drawback is that if I want to incorporate something outside of my usual development environment, I have a lot of work to do because I have to build it myself.

Recently, though, I found myself turning to pre-packaged distributions for a project--and greatly appreciating the convenience they offer.

I have packaged up a Mac build of a popular Python-based card game, PySolFC. PySolFC is a complex package that builds on many components, including the Python PyGame library and the Python Image Library (PIL)--themselves both highly complex Python extension libraries that also build on many external libraries. I've tried to build both PyGame and PIL myself from source many times, in order to integrate them into my custom Python builds, but my efforts haven't worked: both PyGame and PIL have too many moving parts, and something always breaks. I tried again, this time using MacPorts to build the dependencies, but that didn't work either: some of the MacPorts packages were out of date or were incompatible with each other.

Finally, after several hours of frustration, I decided to try the binary installers from ActiveState, both Python and Tcl/Tk. I moved my own builds out of the way and installed the ActiveState packages. ActiveState also provides various extension packages for Python and Tcl, and I used this method to install PIL. Finally, I used a binary installer of PyGame provided by the PyGame developers. Then, I ran the build of PySolFC using the py2app tool. The build worked out of the box. Total time spent using the binary tools: about an hour.

In this case, I definitely appreciate the convenience that the binary packages offer. The complexities of building a library like PIL become someone else's headache (just as these are my headaches if it's my own software that I'm working on). I wanted a working build of PySolFC; the binary packages, which provide the foundation for PySolFC, make it easy to build.

This process has given me some definite insight into the differences between being a developer of my own software and a packager of someone else's. In my own software, I want to push the limits of my toolset. That's why I'm working with Tk-Cocoa now, before it is mainstream, and also why I'm working with 64-bit applications. When you are working on the leading edge, sometimes things are difficult: for instance, I have to use the older, less capable bundlebuilder tool to wrap my 64-bit Python applications, because py2app doesn't yet handle 64-bit programs gracefully. (py2app is more powerful than bundlebuilder, scanning your application and mapping out dependencies as well as building application bundles, and as a result requires more changes to integrate successfully with 64-bit builds; bundlebuilder simply copies code libraries that you specify into an application bundle, and knows nothing about different kinds of builds.) The current maintainer of py2app, Ronald Oussoren, is also the maintainer of Python on the Mac and the maintainer of the PyObjC Cocoa-Python library. Needless to say, he's stretched pretty thin, and hasn't had time to update py2app in some time.

As an application developer, I want to push the limits, but as an application packager, I just want something that works, that has been thoroughly tested and debugged. Using the ActiveState binary installers for Python and Tcl/Tk, and py2app, I was able to efficiently build PySolFC. The built program doesn't reflect the cutting edge of Tcl/Tk or Python--it's not built on Cocoa, nor is it 64-bit capable--but it works great, and just as importantly, it was easy to build. I definitely appreciate the convenience offered by the binary installers!

Finally, since I release a great deal of my own work as open-source, I'm helping to contribute to the next generation of stable binary packages. ActiveState's beta build of Tk-Cocoa now includes some of my libraries. When this beta version (actually Tk 8.6) is finally released in the next year or so, hopefully the cutting-edge advances it includes will become more mainstream.

[/general] permanent link

Tk-Cocoa is the best cross-platform toolkit for the Mac

I'd like to make a bold claim: Tk-Cocoa is now, in terms of its platform-specific integration, the best cross-platform toolkit for OS X.

With the release of tclservices, Tk-Cocoa now has a range of core features and extensions that no other cross-platform GUI toolkit can match. In other words, Tk-Cocoa provides fuller access to Mac-specific technologies--the features and user experience that help define the Mac--than any other toolkit.

Here's how I support this claim:

• Services: With the tclservices package, Tk-Cocoa allows Tk applications to be both providers and consumers of services via the Services menu. No other toolkit--not wxWidgets, not Qt, not Gtk, not Java--supports this. Java allows Mac applications to access the Services menu, but provides no simple mechanism for providing them.

• AppleScript: With its built-in AppleScript support via the "do script" command, Tk-Cocoa allows any Tk application to provide AppleScript support that goes beyond opening documents, launching the application, and so on. No other toolkit--not wxWidgets, not Qt, not Gtk, not Java--supports this.

• Mac-specific window styles: Tk-Cocoa provides, via its core features and extension packages, access to such features as sheets and drawers. Qt provides full access to Mac-specific window styles, while Java provides access to sheets. Neither wxWidgets nor Gtk provide this.

• Displaying Mac-native icons: Tk-Cocoa provides, via core features and extension packages, the ability to display Mac-native icons in an aplication. Qt and Java support this; wxWidgets and Gtk do not.

Does this mean that Tk-Cocoa is superior to these other toolkits? No, certainly not. Tk still lacks some significant features, most notably platform-native printing and a modern HTML library like WebKit. But if you're looking for platform-native integration, no other cross-platform toolkit offers as much specific support for these features as Tk-Cocoa.

I hope this brief discussion may persuade other developers to take a closer look at what Tk-Cocoa provides.

[/general] permanent link

Is Tcl/Tk dying?

A hardy perennial among Tcl/Tk developers is hand-wringing over the language and toolkit's standing relative to other languages and toolkits. At one time Tcl/Tk was one of the most widely-used programming combinations around, but in recent years it seems to have lost some popularity and mindshare among programmers and companies. Tcl/Tk developer Mark Roseman has posted an amusing satire about this question. David Welton has also recently posted a more serious consideration of this question. His analysis, which focuses on both the technical and cultural reasons for this erosion in popularity, is astute.

Still, even after acknowledging the relative decline of Tcl's mindshare and community size, I still have to believe that it's little more than an inconvenience--not a fatal liability--because the core language and toolkit are still being actively developed.

Make no mistake: Tcl/Tk's small community and mindshare are definitely an inconvenience. In Perl or Python, if you're looking for a library or extension package, it's more likely that someone, somewhere has done it already, because their communities are larger. In Tcl/Tk, you often have to do it yourself. In some instances, the functionality I'm looking for is quite difficult to implement (such as SSH support) or is already fully available in another language (such as RSS parsing); in these cases, I may turn to a language that already supports them, such as Python. And even when I do undertake an extension project, such as adding drawers and sheets, I'm often completely on my own because no one else in the community has the expertise or time to offer insight or assistance. Most of my recent posts on the Tcl-Mac mailing list go unanswered because they involve rather complex questions about the integration of Tk and its underlying Cocoa implementation. In fact, it's not an exaggeration to say that the number of active developers of the Tcl-Mac community (contributing to the language's core or with widely-used extensions) can be counted on one hand.

But these problems are an inconvenience--not a showstopper. I am usually able, eventually, to work out any problems I encounter in developing Tk extensions. And, more importantly, Tcl and Tk are getting development where it counts most. While the releases and improvements don't come as frequently as some other languages, they do come--and there are real improvements. Of course, many of these improvements are undertaken by the scrappy core team of Tcl/Tk developers. Some of them, however, are the result of corporate sponsorship, which contradicts those who say that Tcl's mindshare is withering.

In fact, I am heavily dependent on the Tcl/Tk improvement sponsored by a single company: Apple. Apple has twice sponsored ports of Tk to run on top of its native GUI frameworks: first Carbon in 2001, and then Cocoa in 2009. Even though the core Tk-Mac community is small even by Tcl/Tk standards, Tk itself is so widely used on the Mac (by Python, Ruby, etc.) that Apple wanted it as a first-class cross-platform GUI library. That support by Apple, especially by sponsoring a Cocoa version of Tk, ensures the toolkit's future on the platform and is the major reason I continue to develop my Mac-only apps in Tk instead of another toolkit.

I feel very confident in Tcl/Tk's future, and am not troubled by its small community. It would be nice if it had a larger community, but as long as the language continues to evolve and grow, then I will continue to stick with it.

[/general] permanent link

Which file search alogrithm?

I'm working on an update to NameFind, and I'm revisiting one of its central design features: the algorithm it uses to search the file system for files with specific names.

From its inception, NameFind has been designed to use the Unix "find" command-line tool. The find tool is very simple in its approach: it recursively scans or crawls the file system by directory, looking for file names that match the search parameters passed to it. It is very accurate, it's real-time (meaning there's no out-of-date information returned by the search), and it does exactly what it's designed to do: find files by name. The drawback to find is that while it's very fast for small searches (of a single directory or directory tree), it is quite slow for full file-system searches. It's not unusual for a full file-system search for a file name to take 15-20 minutes, and even to cause NameFind to appear to lock up while it's waiting for the search to complete.

User complaints about NameFind have tended to focus on its speed and responsiveness, and so I've tried to find ways to speed up the search process, or at least make it feel more responsive. This is leading me to look at other search algorithms as well. Unfortunately, though, these other algorithms have drawbacks of their own.

By far the fastest tool for searching the file system is the "locate" command. Locate works similarly to find, searching for file names that match a particular search term. It does so by scanning an index rather than recursively trawling the file system: as a result, it is much, much faster. However, the database that locate uses is updated, by default, only once a week; the obvious danger here is that its output may be outdated. It may list things that have been deleted and miss things that have been added since the last time the database was updated. As a result, while its speed is a huge plus, its accuracy is not. And while it is possible to update the locate database manually, it is a lengthy process, and doing so would detract from the user experience I'm trying to offer with NameFind.

A third search option is "mdfind," which the Mac's command-line interface to the Spotlight search system. I originally wrote NameFind as an alternative to Spotlight because I did not find Spotlight's features especially useful for searching for specific files in specific directories. mdfind does have command-line switches for searching in specific directories for specific file names, and its output is faster than "find" because its search is based on a database search, not a real-time directory crawl; unlike locate, the Spotlight database is continually updated in real time. However, mdfind does have problems with accuracy, or at least relevancy. Spotlight, and therefore mdfind, indexes based on file content as well as file name and other data; it may return hits based on the search term being contained within the file's content, instead of its name. Spotlight also does not index certain kinds of data by default (system/hidden files, application bundles, etc.). Finally, while the built-in version of Spotlight translates its raw search output into user-friendly titles and icons, the command-line mdfind tool returns raw search data (instead of an e-mail message, it returns something like "/Users/kevin/Library/Mail/POP-kevin@11.1.1.1111/Deleted Messages.mbox/Messages/718453.emlx"). Looking more closely at mdfind, I'm reminded of why I didn't use it from the start.

Looking at all of these alternatives, none of them is perfect. But, despite its speed drawbacks, the find tool is best suited for my design goal: to find files by name. NameFind is especially useful and fast if I'm trying to search a single directory or two with a lot of files in it; for shallow directory searches, it's better suited than any of the alternatives. It's not as good for a full-system search; while I can probably tune up its responsiveness a bit so it doesn't feel so sluggish, I can't speed up the actual search process itself. Nonetheless, I am going to retain "find" as the engine that powers NameFind.

[/general] permanent link

Which HTML renderer?

One of the most comical aspects of my programs over the years has been my repeated gear-shifting over how to display help documentation in my applications. Apart from the other reasons I've discussed--dissatisfaction with Apple's built-in help viewer chief among them--part of the issue has been my continuing search for a suitable HTML renderer. Tk offers several different approaches, but none are optimal.

For the past couple of years I've been using my own html display package, tkwebview. It's an updated version of an ancient Tk package (mid-1990s vintage), built on Tk's text widget, that can parse and display basic HTML. This package has the virtue of simplicity, being composed entirely of scripts, and it doesn't require any additional compilation. However, it's rather slow to render HTML, and when an HTML pages has numerous images, its scrolling performance is noticeably slow and jerky. (An unavoidable limitation of Tk's text widget.)

As a result, earlier this year I examined two other HTML rendering packages, both of which are written in C and require compilation: TkHTML 2 by D. Richard Hipp, and its successor, TkHTML 3 by Dan Kennedy.

TkHTML 2 is a fast, lightweight renderer for basic HTML. Over the years it has been widely adopted, documented, and supported by Tcl/Tk developers, which means that it is fairly easy to adopt and use in applications. The main problem with TkHTML 2 is that it is rather old (last updated in 2002), only supports basic HTML with no support for more recent web advances such as Cascading Style Sheets (CSS), and is hard to build, at least on the Mac. (A colloquial term for this is called "bit-rot," meaning that the code has not kept up with its environment.)

TkHTML 3 is an ambitious attempt to provide a more modern HTML rendering widget for Tk that supports both CSS and JavaScript. It underwent intensive development from 2005-2007, and in that time, an impressive, nearly full-featured, TkHTML-based browser (HV3) was one result. However, development on TkHTML 3 has come to a complete halt, and the widget has not gained widespread use among Tcl/Tk developers. It is considerably more complex than TkHTML 2, and no common set of best practices for incorporating the widget into an application has emerged (in sharp contrast to TkHTML 2).

After evaluating both options, I finally opted to use TkHTML 2; George Petasis, the author of several widely-used Tk extensions including TkDND, assisted me in getting it built for OS X. While TkHTML 2 is essentially obsolete, it is sufficient for my modest needs: it displays basic HTML, much faster than my earlier text-widget-based package did. It provides everything I need, and nothing more. It would be nice to take advantage of TkHTML 3's features, but I would be largely on uncharted ground: I'm not aware of any simple TkTHML 3-based help viewers out there, just the enormous HV3 browser (which is overkill for my needs).

Another, intriguing possibility down the road is to tap into the Cocoa-native WebKit frameworks on OS X. Daniel Steffen put together a sample project that embeds a Cocoa WebKit view inside a Tk widget. Very cool. However, at present, this method does not allow fine-grained control of the HTML view from Tk; all of that is turned over to Cocoa. For instance, I want to be able to control whether a page is displayed in the web view or loaded into an external browser; WebKit provides hooks for this, but it's not clear to me whether they can be controlled from Tk or not. As a result, I won't be integrating WebKit into my applications anytime soon, although that may be a longer-term project after my other projects--and new applications--are released.

[/general] permanent link

More Tk infrastructure

The blogging has been quiet lately, and work on new applications is on the back burner right now, but I'm plenty busy. I'm working on some low-level Tk infrastructure projects to fill in some serious gaps in the toolkit's functionality.

The first project is porting TkDND to run on OS X. TkDND is a Tk extension that provides platform-native drag and drop capabilities to Tk windows. While this package has been in existence in one form or another for nearly a decade, it's never been supported on the Mac, just Windows and Unix. With Tk finally running on Cocoa, I've decided to add TkDND to the Mac. I'm making good progress on implementing "drop" support--dragging files, text, and URL/bookmarks from the Finder and other applications to a Tk window. "Drag" support--dragging text and other elements from a Tk window to the desktop, for instance--is proving much harder, and I may not implement that feature. (This feature is also missing from TkDND on Unix.)

Drag and drop is the most important project. After this is done, I plan to look at implementing Mac sheets for windows other than dialogs in Tk (dialogs, such as message notifications and saving/opening files, already work as sheets); native (Cocoa-based) Mac printing; and providing additional methods to access native Mac icons in Tk. All of these projects will be released as open-source when they're finished.

It's common for unpaid, open-source programming to originate from the developer's desire to "scratch an itch"; that's true in my case. Sheets, drag-and-drop, and native printing are all features that I've wanted in my own applications for a long time. Until this year my programming skills in C/Objective-C/Cocoa were not equal to the task. I'm still no expert in Cocoa or Tk at the C level, indeed I still have much to learn, but now I feel competent to take on these projects. When they're done, they will make my Tk applications much more pleasant to use.

[/general] permanent link

64-bit Tk-Cocoa and embracing limits

After releasing NameFind last month to mixed reviews, I am now knee-deep in updating my applications to work as 64-bit programs under Tk-Cocoa.

I'm finding some pleasant surprises. Many minor interface glitches and performance problems that persisted under Tk-Carbon have magically disappeared under Tk-Cocoa. Some users, for instance, complained about slow scrolling and image redraw in NameFind, which draws a lot of images in its tableview. The higher performance of 64-bit seems to have fixed this problem. Similarly, the broken help menu search function in Tk-Carbon now works as expected in Tk-Cocoa.

I'm also finding some knottier issues that Tk-Cocoa can't magically fix. A couple of reviewers of NameFind complained about the way its toolbar is laid out. Doesn't look native, they grumbled. They're right. It's a custom Tk-based toolbar widget that tries to imitate the Cocoa-style toolbar--not very well, in their view.

This is actually a very hard problem to solve. The "unified toolbar" style that started with Cocoa applications and is now very prevalent on the Mac is not easy to implement in Tk. I've tried patching Tk at the C-level to draw a metal-style, textured window in a way that integrates well with Tk--but it has major problems with screen redraw, flickering when the window's resized, and so on. It looks good at first, but induces more and more nausea as you go on. So I've abandoned metal windows.

I'm starting to come to terms with the fact that even as Tk is now a 64-bit-capable, Cocoa-based GUI toolkit, thanks to Daniel Steffen's hard work, Tk still doesn't entirely fit in to Mac UI fashions, and perhaps never will. A huge amount of work I've done over the past few years has been fueled by my insecurity about this issue. Perhaps it's time to stop worrying about this issue altogether. It focuses on Tk's limitations, rather than playing to Tk's strengths--it's a powerful toolkit for rapid development. Its customizability means one can go a long way toward making it fit in with its platform, but it does have limits.

I'm wondering if, instead of trying to emulate the UI fashion of the week on the Mac, I should focus on following the best practices of the leading commercial Tcl/Tk application developer, ActiveState. ActiveState makes developer tools for scripting languages, and targets Windows, Unix/Linux, and OS X. It makes extensive use of Tk in its applications, some of which cost several hundred dollars.

Here's a screenshot from the Mac version of an ActiveState product, the Perl Dev Kit, which uses a Tk GUI:

Looking at this, you'll see that this application has a very polished user interface, and one that fits in fairly well on OS X. It uses native widgets in its table display--the discolosure triangle, the Aqua column headers, the system shading in the window, and so on. It also uses native buttons in the toolbar. The toolbar itself isn't native, but does it really look that out of place? Having played with a demo version of this application, I think it's quite professional, and does not feel out of place at all.

I've spent years trying to work around the fact that Tk isn't completely native on the Mac. Striving to fit in with the platform has yielded fruitful results. In general, the UI polish of my apps has greatly improved. Incorporating user feedback has helped improve the usability of my programs. Paying closer attention to these issues has also allowed me to contribute feedback and even code to Tk's core on the Mac, where the native platform integration takes place--and where improvements in the integration pay the biggest dividends. I will continue to do this as time allows; I have some open-source projects on my plate for later this year that will continue my work along this path.

But I have to wonder: does the toolbar in NameFind really look better than the toolbar in the ActiveState application?

I used to think so; I've spent a lot of time trying to achieve the "iconbutton" look of the Cocoa toolbar, in which just the image darkens. But now I'm not so sure. Perhaps my time might have been better spent in adding features that would really make my programs unique. A basic "button bar" would have taken much less time, much less trial and error, and, as the ActiveState application shows, would have looked no less professional.

As I get closer to releasing a 64-bit version of NameFind, and bringing the rest of my applications to the 64-bit Tk-Cocoa foundation, I'm leaning toward leveraging Tk's strengths for rapid development of a polished user interface, and not worrying so much about where it doesn't perfectly integrate with OS X.

[/general] permanent link

Tk-Cocoa: A step back

I'm shifting gears a bit, and pulling back from Tk-Cocoa to focus on new application development. After using Tk-Cocoa to get a new application almost ready for release, I've found a couple of major bugs that have reminded me that Tk-Cocoa is still very much in a beta state. It hasn't undergone widespread production use, nor (to my knowledge) been tested much by outside developers besides myself. So, while I remain very excited about its new features and promise, my use of Tk-Cocoa for now is going to be focused on testing, bug reporting, and bug fixing.

In the meantime, I have about half-a-dozen applications in the works, and Tk-Carbon remains a stable and not-yet-obsolete platform for developing them. So, over the next several months, I'll plan to release several new applications. After that, it's my hope that Tk-Cocoa will be fully ready to rock!

[/general] permanent link

More than skin deep

I get inspiration for GUI design from some unlikely sources:

This homely screenshot is from PgAccess, a now-defunct Tcl/Tk GUI for the PostgreSQL database. You may wonder why I draw inspiration from a database GUI that uses ugly icons, and seems more at home on Unix than on the Mac.

The reason is that this user interface, although not as slick as what you typically see on the Mac, is considered examplary in the Tcl/Tk community for the quality of its UI design. Here's what I like about it: