The example of PgAccess is a major reason why I incorporated these particular widgets in my applications: see this entry for an example of how I use them in my programs to implement Cocoa-style GUI's in my programs. The fact that PgAccess hardly looks like a Mac application doesn't mean much; the cosmetic aspect is actually the easiest one to deal with. Using more modern, Mac-style icons, setting colors and spacing accordingly, and you get very close to Mac conventions without too much effort.

I have considered using other widgets in my apps. BWidgets is not actively developed anymore, and it's quirky--some parts of it are powerful, such as the tree, but other parts of it are broken and nearly unusable. Tablelist is actively developed, and is one of the simplest-to-use and best-documented Tk widgets available--it has earned its considerable popularity among Tcl/Tk developers. However, it is most useful for simple list displays, and can't do certain things that other widgets can, for instance blending a tree and list display in the same view. (See the Finder for an example of how this works.) Also, both widgets are script-level (Tcl-based) widgets, and thus are slower than widgets coded in C, a compiled language.

TkTreeCtrl is an extremely fast, powerful widget code in C that can do just about anything you want, but it is enormously complex. (The tutorial for TkTreeCtrl is intimidating in itself.) TkTreeCtrl is widely used in commercial Tk applications with complex GUI's, but it is probably overkill for my needs; also, as a binary extension that requires compilation, it's not clear whether it will work with the forthcoming Tk-Cocoa branch of Tcl/Tk.)

Another, somewhat less complex widget is the ttk::treeview widget that is new in Tcl/Tk 8.5. It can provide a tree, list, and combination view, something that neither the BWidget or Tablelist libraries can. It also compiles just fine with Tk-Cocoa. However, the ttk::treeview widget lacks some important functionality that comes out of the box with Tablelist, such as sorting of data in the display. Tablelist supports this with a single command, but a developer has to add this to ttk::treeview. Also, ttk::treeview lacks visual cues to indicate when data is sorted, such as an up-or-down arrow in the column view. Again, Tablelist includes this out-of-the-box. Finally, it's not clear to me how configurable ttk::treeview is; developers' general experience with the ttk themed widgets is that they are great in their default values (they are designed to conform to platform conventions out of the box), but they are much harder to customize.

Given that I'm able to do nearly everything I want to with BWidgets and Tablelist, it's likely I will continue to live with their minor drawbacks and use them in my applications. And I trace that all back to PgAccess--homely on the surface, but clean and designed with care.

[/general] permanent link

Tk is easier than Cocoa

While doing a bit of research on how Cocoa developers create user interfaces, I was struck by the difficulty this developer faced in trying to create a user interface similar to that used by Apple in several of its applications:

"That's what I wanted for my new application: a source list on the left, a content list on the right, and a detail view below that. All with no margins. Unfortunately you just can't whip this up with Interface Builder."

This seems hard to believe, but the developer had to do a huge amount of work to implement the basic interface. He wound up collecting code components from several different sources--one package implemented a "split-window" view, another implemented a gradient list selector and icons in the list, another implemented custom layout in a table's cell, and so on.

The results are below:

Nice, but hardly easy or rapid--the major arguments that Cocoa developers make for their toolkit.

Here's what I use in Tk to achieve a similar interface: a BWidget Tree on the left, a Tablelist view on the right, and a text view below that, all wrapped up in ttk::panedwindow or two, and with their appearance options (such as the background, the list selector, etc.) customized to match OS X conventions.

Here are the results:

Fortunately, you can whip this up in 150 lines of code, or thereabouts. (That 150 lines doesn't include the code for the toolbar, search field, and so on, but this is an apples-to-apples comparison.)

I'd suggest that my Tk interface is very close in its appearance to the native Cocoa interface developed with Objective-C code...and I was able to develop this basic approach with far less work than the custom Cocoa interface, leveraging components that are either part of the Tcl/Tk core (text widget, paned window) or part of the standard Tcl/Tk extension library, and thus well-maintained and readily available.

I'm sure this example won't persuade any Cocoa developers to give Tk a try--heavens no!--but it does show the surprising power that Tk has, and demonstrates why I choose to develop my programs with this toolkit.

[/general] permanent link

Evolution

A recent favorable comment about Phynchronicity online--the commenter said that Phynchronicity "has evolved into a fine package"--was very gratifying, and also thought-provoking. The idea of "evolution" is what spurred my thinking, because this is a very accurate description of my approach to development.

When I begin developing a new program, I have a certain number of features and functionality in mind. My basic strategy is to implement the absolutely essential features and functionality in version 1.0, with an eye to getting the program out as soon as possible. Some refinement and polish of the program occurs after this point, especially in response to user feedback. However, my main goal is to implement the rest of the major features I've envisioned and move to version 2.0 in a reasonable time frame.

Once I reach version 2.0, I usually shift gears away from a big laundry list of new features, and my approach becomes much more evolutionary. Some developers use the laundry list approach as way of demarcating major versions of their software, to 2.0 and 3.0 and beyond, and also as a way of justifying upgrade charges. That's not how I prefer to do things. Once I get to a point where a program does what I want it to do, I want to continue to improve it by refining its polish and usability--not by dramatically changing the scope of what it does. This approach doesn't rule out new functionality and new features, but it does rule out a huge number of new features that may bear little resemblance to the program's original purpose.

That's how Phynchronicity has evolved. The program's core functionality--installing and removing software--has remained from the start. What has changed is how the program goes about its tasks, and the experience it presents to the user.

When I first started work on Phynchronicity, it installed and removed software, but it was slow, ugly, and unituitive. Today I started version 1.0, and almost laughed at how unpolished it was. I then looked at version 2.4, which was just released earlier this week, and the difference was night and day. This is what the comments above focused on--initial reviews of the program complained about version 1.0, while version 2.4 is what the current comment was based on.

Between version 1.0 and 2.4, here's what changed:

With the exception of one big jump--to version 2.0--all of these changes and enhancements were added bit by bit over time. The change from version 2.0 to 2.1 did not seem like a big jump, for instance--just a few little tweaks and enhancements. But the sum total of these enhancements is a program that is vastly improved, indeed one that bears only a passing resemblance to the program it was when first released.

This evolutionary approach to software development is one reason why I shy away from charging upgrade fees--it's hard for me to draw a line in the sand and say that this update is big enough to merit an upgrade fee. Over a couple of years, the changes are dramatic, but not from one released version to the next. Still, even if this means I'm passing up some revenue, I still prefer this iterative, evolutionary approach to the "laundry list of features" approach. I think it means better software over the long run.

[/general] permanent link