Code by Kevin

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.


Archives
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

October 2017
Sun Mon Tue Wed Thu Fri Sat
       

Privacy Policy

Site design: Skeleton

 

Fri, 11 Dec 2009

Finally, Tk-Cocoa extensions

I'm pleased to announce the release of three Mac-platform-native Tk-extensions that build on the Cocoa frameworks to integrate with the new Cocoa-based version of Tk for the Mac.

Macsheet

This package implements Mac-native "sheet" windows for Tk. "Sheet" windows are dialogs or toplevel windows that slide down from the top of a Mac toplevel window, and then slide back up when they are dismissed. Tk on the Mac has long supported the "sheet" effect for system dialogs, such as tk_messageBox, when a "-parent" option is passed to the call. The macsheet package adds the ability to create customized dialogs or windows with a similar effect.

Tkdock

The tkdock package allows a Tcl/Tk application to manipulate the Dock icon. The package allows an application to change its icon on the OS X Dock while running; it also allows the application to set a badge label to the Dock.

Tkmacicon

The tkmacicon package renders platform-native icons on OS X as Tk images. The ::tkmacicon::retrieveicon command takes three arguments: a file path or file extension, width, and height. If a file path is specified, then the package will return the specific icon for that file as defined by the Mac OS, in the width and height specified in the arguments. If a file extension is specified, then the package will return the specific icon for that file type as defined by the Mac OS, in the width and height specified in the arguments. Specifying the file extension rather than the actual file can yield faster performance for large numbers of files.

All three packages are available at http://tk-components.sourceforge.net/ and are licensed under Tcl's BSD-style license. Both file releases and SVN downloads are available. In addition to source code, the packages include demo scripts and man pages.

These extensions require Tk-Cocoa to run; they are not compatible with the older version of Tk based on the Mac's Carbon framework. Tk 8.6 for the Mac is based on Cocoa, and a backport of Tk-Cocoa to 8.5 is available at http://github.com/das/tcltk/tree/de-carbon-8-5.

[/software] permanent link

Thu, 26 Nov 2009

More progress on adding features to Tk-Cocoa

First, the good news...

Drag-and-drop. I'm making some good progress on my project to port TkDND to OS X: I've successfully gotten Tk widgets to recognize files and strings of text that are dragged to it. I still have to do some work on integrating my code with TkDND itself, which will take some time--but the hardest part is over. I won't be implementing drags from Tk windows to other Mac windows or the Finder/desktop, because that's considerably more complicated. Even with this limitation, being able to drag files and text directly to Tk windows will be a big improvement in usability and Mac-native integration.

Custom sheets. Tk has long supported "sheets"--dialogs that slide down from the window--with standard system dialogs, file choosers, and so on. It hasn't supported custom dialogs that a programmer may choose to implement, such as a password dialog. With just a couple of days of work, I've got a decent implementation put together. The slide-down of custom dialogs isn't as smooth as system dialogs (because of some differences in how Tk draws windows and how Cocoa manages the "sheet" effect), but it's good enough for my requirements--and again, a nice improvement in usability and integration. I've gotten the Cocoa-level code working fine; I have to add some additional script-level code (based on the prototype code I've been hacking on) to make the package complete.

Next, the bad news...

Native Cocoa printing/dialogs. I've decided not to attempt to develop a Tk extension that provides system-native (Cocoa-based) printing. The command-line tools to support printing on OS X are superb, as I've discussed before, and native printing dialogs simply won't offer a huge improvement over what I am already doing. My one serious motivation for exploring native printing was the inability of the command-line tools to print HTML well. I've been using an open-source tool called HTMLDoc to generate a PDF file from HTML, which I can then print via the command-line. HTMLDoc does a good job, but it is a large program, and because it is licensed under the GPL, I have to include the source code for the program with my applications; the combination of these two things greatly increases the size of my applications. However, more recently I've run across a command-line tool called wkpdf--a Cocoa-native WebKit (HTML)-to-PDF tool that uses the Cocoa frameworks for the conversion. It's much smaller than HTMLDoc and works a bit better, to boot, so this solves my HTML-printing problem. As a result, I have no real need for a Cocoa-native printing solution, and won't be pursuing this.

Finally, on the to-do list...

Dock icons and native Mac icons. I've developed several packages in the past year to integrate native Mac icons in my applications, to modify the Dock icon of my programs, and to add a badge to the Dock icon. Some of these I've released as open-source, and some I haven't. I plan to do a bit more work on expanding and polishing the capabilities of these extensions; then I will do a big release of them. It's my hope that others will find my work on these projects beneficial, but I'm doing them first and foremost to improve the capabilities of my commercial applications: that's why I have to pick and choose among the many possibilities for (unpaid) open-source work that I run across. I've been working on these projects for several weeks now, and eventually I need to get back to working on applications that users pay for. After this round of projects is done, my applications will have several new capabilities, which will make them more pleasant to use.

[/software] permanent link

Thu, 19 Nov 2009

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

Tue, 20 Oct 2009

Tk-Cocoa and input managers

I now have no doubt that my Tk-Cocoa applications are "real" Cocoa applications: they are susceptible to input managers.

An input manager is an arbitrary Cocoa extension that loads into every running Cocoa application (because it loads into the Mac's Objective-C runtime). Originally designed to allow for alternate methods of text input, it is now more commonly used to inject code into any or all Cocoa applications. While this is most frequently done to add functionality to a specific application, it can pose a security risk for your system by allowing the injection of malicious code into the Cocoa runtime. Even if it doesn't do that, input managers can also have unintended side effects on random Cocoa applications.

I got a bug report about such an unintended side effect over the weekend. An application user mentioned to me that Manpower was crashing. After reviewing some crash logs provided by the user, I found a reference to an input manager installed on the user's system, along with the error message "GC capability mismatch." ("GC capability" refers to whether an application was compiled with garbage collection--a method of automated memory management--or not; Tk-Cocoa makes use of GC, but many Cocoa applications do not.)

This is an example of an unintended side effect. Neither Manpower nor Tk-Cocoa itself had anything to do with the input manager in question, but because the input manager was exposed to every application that makes use of the Cocoa runtime, this conflict caused Manpower to crash. I advised the user that, as with AppleScript osax extensions, the only solution is to uninstall the input manager.

So, if you're experiencing crashes with any of my applications, input manager conflicts are something else to look for. Ah, the brave new world of Cocoa!

[/software] permanent link

Sat, 17 Oct 2009

New download links

After launching Cocoa-based versions of all my applications last week, my server was hammered by download traffic. This was the largest release I'd ever done, and the download size of all the applications was larger than before (a consequence of adding universal 64-bit support). As a result, I received numerous complaints about slow downloads or, worse, inaccessible downloads.

Too much traffic is a good problem to have, but paradoxically, there's a danger that I might lose customers. To quote Yogi Berra on a fashionable restaurant: "Nobody goes there anymore. It's too crowded."

That problem has been solved by moving my download links to Amazon S3, a cloud-based Internet storage service managed by Amazon. S3 is an inexpensive solution for Internet-based storage and downloads, and other Mac indie developers have recommended it highly.

As a result, traffic on my server is back to normal, and downloads should proceed at a snappier pace. If you've been trying to download one of my apps but found it impossible, try again--you won't be disappointed.

[/business] permanent link

Tue, 13 Oct 2009

The big bang: Tk-Cocoa integration complete

Today's a milestone: the migration of my applications to Tk-Cocoa is complete, and I'm releasing all of them on the same day.

A couple of years ago, when Apple announced that Carbon was going to be deprecated, I worried about the future of my software business. My toolkit of choice, Tk, was built on Carbon, and no clear roadmap for integrating Tk and Cocoa existed. Would I have to abandon Tk and rewrite my applications from scratch in Cocoa or another toolkit?

Happily, two years later, those fears have proven to be unfounded. Apple itself sponsored the porting of Tk to run on top of Cocoa, and Daniel Steffen, the maintainer of Tcl/Tk on the Mac, capably handled the port. As I've written before, Tk-Cocoa offers many improvements over its previous Carbon-based incarnation: better native integration with the OS's UI guidelines, more UI polish, and (most of all) better performance, because it is 64-bit capable.

I've done some UI freshening of my applications, and have fixed numerous bugs in them, but the major feature is simply their migration to Tk-Cocoa. All of my Tcl/Tk applications are fully 64-bit, and their performance is notably better. Because of some issues with Python's application deployment tools, my Python applications are hybrid 32-bit/64-bit (the Tk part is 64-bit, the Python part is 32-bit), but I anticipate this will be fixed in the near future. In every case, the applications have more UI polish. Every release is now a version upgrade (2.0 to 3.0), not just a point release (2.0 to 2.1). Despite the improvements, I'm holding the line on prices, so my applications are a better value than ever.

I'm very grateful to Apple and Daniel for bringing Tk on the Mac to the next level. Tk-Cocoa will provide a stable platform for my applications for years to come, and I am very near the day when I can focus exclusively on application features and not banging against the limitations of my chosen toolkit. In turn, I expect this will lead to more and better application development, and growth of my software business.

I'm so excited! If you want to celebrate with me, check out the applications, and let me know what you think...

[/software] permanent link

Mon, 05 Oct 2009

64-bit Adobe osax files

I've continued to get some reports of PortAuthority crashing on Snow Leopard. As I discussed in a previous blog entry, these crashes are often the result of AppleScript conflicts caused by 32-bit "osax" files. The most common offenders that I've run across are osax files installed by Adobe in support of its Photoshop program. Not surprising, given that Adobe is the heavyweight vendor of graphic and publishing software for the Mac.

I was pleasantly surprised today to hear from a user that Adobe has quietly updated some of its osax files to support 64-bit. You can see the details and file downloads in this technical note. So, if you're having problems with PortAuthority or any of my other programs and traced the problem to conflicts with Adobe osax files, try updating the offending files and see if that solves the problem.

[/software] permanent link

Tue, 22 Sep 2009

PortAuthority and Snow Leopard

While I haven't updated to Snow Leopard yet, I've gotten some reports of PortAuthority crashing on Snow Leopard. Sometimes these errors can be hard to debug.

Here's a quick way to see what might be happening: run PortAuthority from the Terminal. Select PortAuthority in Finder, right-click on it, and select "show package contents." Navigate to Contents/MacOS and double-click on the "PortAuthority" file--this will launch PA in Terminal and print any error messages there. Copy the error messages and send them to me in an e-mail--this will help me diagnose the problem.

Based on the error reports I'm seeing from users, the issue is almost always a problem with an AppleScript scripting addition: a file that has the extension "osax." These are usually installed in /Library/ScriptingAdditions. Various programs install these files to extend the Mac's built-in AppleScript scripting language with additional functionality. These files are typically 32-bit packages, which is the standard on OS X up through Leopard. Snow Leopard, however, makes most system components 64-bit, and if installed third-party libraries do not include 64-bit support, they'll cause conflicts.

What's happening is that PortAuthority is crashing when it tries to use AppleScript to communicate with Growl, the nifty open-source notification system for OS X. If one of these incompatible "osax" files is installed on the system, it will cause issues with AppleScript, and hence PortAuthority.

The only solution, at present, is to move the offending "osax" file out of the way, to a different folder than the /Library/ScriptingAdditions. Thus far, this has allowed PortAuthority to run without problems.

By the way, the same issues may also affect my other applications. If you're seeing obscure crashes on Snow Leopard, give the above instructions a try.

[/software] permanent link

Sat, 19 Sep 2009

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

Wed, 26 Aug 2009

Priorities

I'm a great admirer of Gus Mueller, the main developer at Flying Meat Software. He's one of the leading indie Mac developers out there: his desktop wiki VoodooPad and his image editor Acorn are leaders in their categories. A few years ago he posted a blog entry that outlined his path to indie success, and it has served as an inspiration for many indie Mac developers, myself included.

Given my admiration for him, I was a bit taken aback by the curmudgeonly tone of his latest blog entry.

A bit of context: Gus's blog entry is based in turn on an Inc. article by Joel Spolsky of Fog Creek Software about how his software company took off: founded right at the moment of the dot-com crash of 2000, Fog Creek struggled financially, laid off employees, found some unexpected success with its bug tracking product FogBugz, tried all sorts of marketing gimmicks to improve sales, then finally settled in to simply improving the product itself, after which sales took off.

There's wisdom here. All the marketing glitz in the world won't help if your product is terrible, or doesn't meet user needs. Marketing helps, but it isn't a substitute for having a great product to sell.

Gus notes that his experience has been similar: improving his own products has been the biggest factor in the growth of his business. And he suggests that if other indie developers aren't succeeding, they should take a look at their own products:

Learn to be your best critic, and you'll learn to ship software that's worth paying for. If no one is buying your app then you've either got a dud and you need to focus on something else, or you need to improve your app so it's worth paying for. And some apps, no matter how flashy or awesome or genuinely useful, will never make money.

His assumptions here are bit surprising: that if someone's application isn't selling, it must be because they aren't self-critical enough. That might be true; the developer might be impervious to feedback, and even have a reputation for being hostile to user input. But it might also be that the product is in a highly competitive market niche. It might also be that there's little demand for the product. It might also be that the product is in the wrong place at the wrong time.

Business success is an inexact process. Quite simply, it's a gamble. If you look at some of Joel Spolsky's other articles, you'll see that luck played a big role in his success. One of his products, FogBugz, took off; another one, CityDesk, did not. Although Gus notes that "some apps...will never make money," I think he underestimates how much luck plays a role.

Applying these lessons to my own software business, I reach the following conclusions:

Having said this, taking Gus's advice and serving as my own toughest critic, I also have to acknowledge: my apps don't sell as much as I'd like. I'm not a full-time indie developer, like Gus. And (bad) luck isn't solely to blame here.

Or, to pose the question, "Why don't my apps sell," I could paraphrase Gus: "Maybe they just suck?"

Well, some people seem to think so. NameFind got a harsh reception at MacZot the other day; at least one user disparaged my professionalism as well as noting specific criticisms of the app itself. (Even amid all the flaming, I extracted at least two suggestions that I will use for further improvement of NameFind, so thanks.)

Most of that user's complaints stem from the fact that NameFind isn't written in Objective-C and Interface Builder; it doesn't hook very deeply into Cocoa. (Parts of it do, but not the whole thing.) That's an unavoidable limitation of my software since I don't develop directly in Cocoa but rather with a toolkit that uses Cocoa for basic UI elements that it organizes using its own API. I have to take my lumps there with whatever "suck" factor might apply. (Some users care more about this than others.)

So I concede a certain amount of lost sales because Cocoa's not part of the equation. I don't believe that's the totality of it, however. Some of my products target niches with established competitors. I probably don't market as much as I should. And, at the end of the day, not every product is going to take off. (Gus himself has discontinued one or two slow sellers over the years.)

Bottom line, it's darn hard to be a success as an indie developer. For every established indie Cocoa developer like Gus, there are probably a dozen indie Cocoa developers whose businesses haven't taken off, for whatever reason. I'll bet dollars-to-donuts that most of those developers are tough self-critics, strive to create the best products possible, and provide user support to the best of their ability. (In short, there are probably more Cocoa developers whose business looks like mine than those whose business looks like Gus's.)

Getting back to the title of this blog entry: I think my priorities are in the right place. It's no guarantee of anything.

[/business] permanent link

Sun, 09 Aug 2009

Resurrection: NameFind 3.0

I've resurrected a program I discontinued two years ago: NameFind. NameFind is a file-search tool for Mac OS X, using acting as a front end for the Unix "find" command that is installed on every version of Mac OS X.

I chose to discontinue NameFind because it sold very slowly, and I saw little opportunity for improvement. File search is a crowded software category on OS X, with both commercial and freeware alternatives, and NameFind at the time had serious limitations, most particularly a non-native GUI and limited feature set. A modified version of NameFind, released as open-source freeware but otherwise little altered from the version I discontinued, has had very few downloads.

So why revive NameFind now? There are a couple of reasons for this.

First and foremost, I've vastly improved my development skills over the past two years. Not only do my programs fit in far better with OS X in terms of their UI design, I am now able to integrate Cocoa technology into my Tk applications. The result is that my programs can do things like change their icon during a long-running process, display a dock badge, and display native icons. System hooks into QuickLook and Growl also make NameFind feel more native. All of these factors make NameFind 3.0 a vastly more polished program than it was two years ago.

Second, I'm more patient than I was two years ago. When I discontinued NameFind, I was looking for a "home-run" program such as Daniel Jalkut's MarsEdit or Gus Muller's VoodooPad--programs that are big, big sellers, big enough to provide a living and then some. Now, I understand how hard that is, and I also understand that modest sales can add up. So if NameFind doesn't become the best seller in its category, that's OK. Given proper marketing, I'm confident it will find at least some users, and it will provide some revenue.

So, if you're dissatisfied with how Spotlight and related search tools on OS X work, give NameFind a try. For finding specific files by name in specific directories, it can't be beat.

[/software] permanent link

Fri, 07 Aug 2009

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

Sun, 19 Jul 2009

Business notes on Tk-Cocoa

As I've previously noted, I have been spending the past couple of months testing Tk-Cocoa as a foundation for my programs. This has involved repackaging one of my previous applications to run on Tk-Cocoa as a way of putting Tk-Cocoa through its paces, filing bug reports and submitting patches to enhance Tk-Cocoa, and documenting my progress. I've also developed some cool Cocoa-based extensions to add specific features to my programs; one of these extensions, TkDock, has been released as open-source and has already been adopted by a couple of programs. In the meantime, I have done no new work on my currently-released programs, which still run on the older Carbon implementation of Tk.

Does this make business sense? Nearly all of the work I've been doing has been an unpaid, volunteer effort. No one pays me to write patches or submit bug reports on Tk, and I don't earn any royalties when someone uses one of my Tk extensions in their work. The past couple of months have been very productive from a coding standpoint, but have not resulted in any updates or new releases of a commercial product.

I think the time I've been spending does make sense from a business standpoint. Everything I've been working on is directly related to the development foundations of my programs, Tcl/Tk and Python. Some of the bugs I ran into were literally showstoppers: they caused Tcl/Tk to crash. It's hardly feasible to release a commercial program that crashes frequently. Also, in terms of patches and enhanced functionality as opposed to bug reports, the code I've been working on addresses a few long-standing gripes about how Tcl/Tk looks and/or works on the Mac. These patches really, really improve a few things and put Tcl/Tk on par with other cross-platform frameworks.

So, in other words, I'm getting a lot of bang for my buck in terms of the time I've spent. I'll be able to fold these improvements into my applications immediately. And, hopefully, that will improve their sales.

The other aspect of contributing to open-source projects is one I've discussed before: it's about giving back. I've benefitted from the labor of an entire community of developers, many of whom are unpaid. (Though, to its credit, Apple apparently sponsored Daniel Steffen's work on porting Tk to run on top of Cocoa.) I am glad to share the improvements I make to Tk with the larger community.

In another sense, as well, the time I'm spending is little different than time spent by dozens of other Mac developers who have to move their code from Carbon to Cocoa. Since 2007, Apple has made it forcefully clear that Carbon is dead, and Cocoa is the future. Tcl/Tk is hardly alone in this respect, and it is not late to the game either. The time I'm spending transitioning my applications to Tk-Cocoa, and the time I spend contributing improvements to Tk-Cocoa, will be abundantly repaid later on--repaid in the continued viability of my products, in their improved capabilities, and continued and increasing sales.

[/software] permanent link

Developer notes on Tk-Cocoa

My previous post focused on the user-visible changes in Tk-Cocoa, and how these will improve Tk applications on OS X from a user perspective. This post will focus on some of the technical changes of Tk-Cocoa, so that developers who have previously deployed Tk applications on OS X can smoothly transition their applications to the new framework. Despite assertions to the contrary, there are some "script-level" changes in Tk-Cocoa--that is, changes that will require adjustments to actual Tcl/Tk code to adapt to Tk's new Cocoa implementation.

Menu Changes

I'll quote from the Tk documentation on how certain menu items are handled, then discuss their practical import:

When Tk sees a .menubar.apple menu as the first menu in a menubar on the Macintosh, that menu's contents make up the first items of the Application menu whenever the window containing the menubar is in front. After all of the Tk-defined items, the menu will have a separator, followed by all standard Application menu items. Such a .apple menu must be present in a menu when that menu is first configured as a toplevel's menubar, otherwise a default application menu (hidden from Tk) will be inserted into the menubar at that time and subsequent addition of a .apple menu will no longer result in it becoming the Application menu.

This means that when you set up a window's menubar, the last menu command you should run is something like this:

$w configure -menu .mb

Otherwise Tk's hard-coded application menu will blow away your custom application menu, and move it elsewhere in the menu display. This works differently than the Tk Apple menu in Tk-Carbon.

As an alternative, you can remove all references to the Apple menu, and define the procedures tkAboutDialog and ::tk::mac::ShowPreferences. These will replace the corresponding commands in the hard-coded Tk application menu. I have found this approach simpler than using the Apple menu. (If you define tkAboutDialog to use the new tk::mac::standardAboutPanel command, you get a Cocoa-native appliction "about" window.)

When Tk sees a .menubar.window menu on the Macintosh, the menu's contents are inserted into the standard Window menu of the user's menubar whenever the window's menubar is in front. The first items in the menu are provided by Mac OS X, and the names of the current toplevels are automatically appended after all the Tk-defined items and a separator.

This is the standard Cocoa "window" menu. This menu item is not present in Tk-Carbon, and so if you want something with that functionality, you have to code your own. (Which in fact I did, with my "windowlist" package. I have not yet decided whether to continue using my own package in my Tk-Cocoa applications or rely on the Cocoa menu, but it makes sense to leverage the built-in capabilities wherever possible.)

When Tk sees a .menubar.help menu on the Macintosh, the menu's contents are appended to the standard Help menu of the user's menubar whenever the window's menubar is in front. The first items in the menu are provided by Mac OS X.

This is the default Cocoa help menu, which looks for a specially formatted Apple Help book in your application bundle and pops up this dialog if one isn't found:

Tk-Cocoa help dialog.

This command tripped me up at first, since I strongly dislike Apple's built-in system for viewing user help and thus don't use it, and I thought other developers might find it confusing as well. If you define your own help command in your Tcl/Tk code and place it in the "help" menu, then your application will display two separate help commands--the standard Cocoa help command, and the one you've defined. This would be very confusing to end users. After providing Daniel Steffen some feedback about this, he implemented the tk::mac::ShowHelp command to override the standard Cocoa help menu item (you can also still include additional items).

Native Icons and Bitmaps

The coolest new feature of Tk-Cocoa is its ability to access system icons natively via the tk::mac::iconBitmap command. Tcl/Tk on Windows has long had this capability, and it's time the Mac got it as well. From the "Readme" file:

TkAqua provides access to native OS X images via the Tk native bitmap facility
(including any image file readable by NSImage). A native bitmap name is
interpreted as follows (in order):
- predefined builtin 32x32 icon name (stop, caution, document, etc)
- name defined by [tk::mac::iconBitmap]
- NSImage named image name
- NSImage url string
- 4-char OSType of IconServices icon
the syntax of [tk::mac::iconBitmap] is as follows:
tk::mac::iconBitmap name width height -kind value
where -kind is one of
-file icon of file at given path
-fileType icon of given file type
-osType icon of given 4-char OSType file type
-systemType icon for given IconServices 4-char OSType
-namedImage named NSImage for given name
-imageFile image at given path
This support was added with the Cocoa-based Tk 8.5.7.

Here's a script that illustrates how the command is used:

toplevel .f

set dir [tk_chooseDirectory]
set filelist [glob -directory $dir *]

foreach item $filelist {

tk::mac::iconBitmap $item 16 16 -file $item

puts "creating iconbitmap for $item..."

label .f.[lsearch $filelist $item] -bitmap $item -text [file tail $item] -compound left
pack .f.[lsearch $filelist $item]

}

And here's what that looks like:

Native Mac icons, rendered by Tk.

This command was causing a hard-to-isolate crash in Tk; thanks to Daniel Steffen for tracking it down and fixing it. Now that the command is stable, it's the jewel of Tk-Cocoa, in my view.

What Tk-Cocoa Can't Do

My last post also said that it wasn't possible to render a "unified toolbar" in Tk-Cocoa. That isn't entirely accurate. Through a combination of Mac-specific configuration items (specifically, setting the window's style to "metal," and drawing many widgets with the "systemTransparent" background), it is possible to closely emulate the unified toolbar, as the screenshot below shows.

Tk-Cocoa unified toolbar.

However, the resulting application window has serious usability issues. The window "flashes" when it's resized, and it can also be dragged around from any point on the window, instead of just from the titlebar, which is standard Mac behavior. (Apparently exposing the underlying "metal" background of the window via the "systemTransparent" background causes some of these issues.) The fact that the window can be dragged from any point makes it hard to select and delete text from the entry field, for instance. It gives the entire window a jerky, unpleasant feel.

In this case, I'm going to forego the native Mac appearance for something that looks a bit less native (see the other application screenshot in my previous past) but is more usable.

There are some other things still missing from Tk-Cocoa as well: native drag-and-drop integration and native, non-command-line printing are two of the biggest gaps. However, these capabilities are not part of Tk's core on other platforms, either, such as Windows. Extensions for such capabilities exist, but they either have not been ported to the Mac or depend so heavily on Tk's platform-specific implementation (i.e. Carbon) that they need to be rewritten for Cocoa.

No matter. All in all, Tk-Cocoa is a big step forward for Tk developers on the Mac, and I hope these notes provide some assistance in getting other Tk applications to work with it.

[/software] permanent link

User notes on Tk-Cocoa

The Tk-Cocoa port has now been merged into the main line of Tk development, and will be the standard going forward as Tk 8.6 moves toward final release. The Tk-Cocoa developer, Daniel Steffen, is also graciously maintaining a version of Tk-Cocoa that is based on Tk 8.5, the current production release of Tk. (It's unusual for such sweeping changes to a programming framework to be incorporated into the current release.)

In using Tk-Cocoa to develop a new application, I've run across a few bugs--errors or problems in the software--that required some fixing. Specifically, the new command to retrieve native Mac icons causes occasional crashes--my program would just quit without explanation. I've also submitted a couple of patches (partial updates to the software) to improve a few of its features: specifically, the notebook widget now uses modern tabs for its layout, and a table column header now renders in standard Aqua blue when it's selected. Both Daniel and Csaba Nemethi, the developer of Tablelist--a table widget for Tcl/Tk that is similar to the table layout you see in the Mac's Mail application--have used these bug reports and patches as the basis for updates and improvements, for which I thank them. These changes greatly enhance Tk's appearance and platform integration under OS X. Note the screenshots below:

The updated Tk-Cocoa notebook display.

The updated Tk-Cocoa column display, with "Aqua-blue" column header and sorting arrow.

Based on these updates, nearly all of my long-term complaints about Tk on the Mac have been addressed. As a result, I'm moving full speed ahead with development of an application on Tk-Cocoa, and I'd like to highlight some of the ways Tk-Cocoa will enhance my software. I'd also like to highlight some of the changes that Tk-Cocoa requires. (Despite the claim that Tk-Cocoa requires no "script-level" changes, this isn't entirely true.)

Tk-Cocoa in Use

Here's a Tk-Cocoa-based screenshot from the application I'm currently developing, NameFind, which is a file-search tool:

NameFind under Tk-Cocoa.

And here's a screenshot from an older version of the application, which I discontinued a couple of years ago, with Tk's older Carbon implementation:

NameFind under Tk-Carbon.

You'll notice some immediate differences. The Tk-Cocoa version uses native Mac icons, retrieved on the fly from the system like other Mac applications, such as Finder. The Tk-Carbon version uses generic images, because it could not render Mac icons correctly. The Tk-Cocoa version also correctly implements the sorting layout of a Mac table view, with the column header rendering its selected status natively ("Aqua-blue"). The Tk-Carbon version didn't support this.

From a user standpoint, the advantages of the Tk-Cocoa version are pretty clear-cut. It offers superior visual integration with OS X, making it easier for users to be productive. No need to take a close look at the file, for instance, to figure out what kind it is; the native icon provides a visual cue. Similarly, the "blue" column header makes it immediately obvious which column is being sorted.

Under the hood, there's another advantage: I've compiled NameFind as a 64-bit application, which is the direction all Macs are going. 64-bit allows increased memory usage, and can improve performance.

Changes that Tk-Cocoa Requires

I'm still discovering some of the ways that Tk-Cocoa differs from Tk-Carbon. For one thing, some commands seem to work a bit differently. As an example, a command for handling window closing and application shutdown doesn't work quite as expected; I think it's a bug, which I've reported on the appropriate Tk developer tracker. I can work around this bug in my programs, but it may require a bit of additional code on my part. I've also found, as you can see in the application screenshot above, that Tk-Cocoa doesn't access certain aspects of Mac UI appearance very well; the "unified" toolbar so prevalent in Mac applications today is an example of this. The help menu, the window menu, and other things also differ a bit. (I'll have more to say about the technical details of Tk-Cocoa in a subsequent post.)

All in all, however, I'm very pleased with the improvements that Tk-Cocoa is allowing my software. My software will benefit from an improved UI appearance, improved 64-bit performance, and continued viability on OS X.

[/software] permanent link

Sun, 14 Jun 2009

Final site tweaks

I've done a bit more tweaking to the Code by Kevin website, and now I'd like to highlight those changes:

After all these changes, I've pleased with the new look and usability of the site. Now it's back to product development, incorporating the latest and greatest from Tk-Cocoa. I'm just waiting for a few more bug fixes and patches to go into TK-Cocoa in the next couple of weeks, and then Tk-Cocoa will move from the "development" branch of Tcl/Tk to the main line of the codebase. At that point, I'll be able to quickly get out a few new products, and I'll also post a detailed blog entry about the improvements that Tk-Cocoa is allowing for my software.

[/business] permanent link

Tue, 09 Jun 2009

Site changes

After getting some feedback on the Code by Kevin website at the Joel on Software business fourm, I've made some pretty significant changes to the site's design. I hope it's simpler and easier to navigate. I welcome any feedback!

[/business] permanent link

Tue, 02 Jun 2009

Dropping Tiger support

A bug report from a prospective customer about one of my products crashing on Mac OS X 10.4 has led me to this discovery: during the last round of updates, I added a feature (calling a specific command-line program) that isn't supported on Tiger, and is causing the crash. This presents a dilemma: do I update the programs to fix the bug so they continue to run on Tiger/10.4, or do I simply leave it alone and not support Tiger anymore?

With the release of Mac OS X 10.6, a.k.a Snow Leopard, likely coming in the next few months, my solution is to drop Tiger support altogether. This decision is driven by the fact that Leopard (10.5) will soon become the "older" supported version of Mac OS X (Apple typically provides security updates and patches, but no new development, for the immediately preceding version of the operating system). It's also driven by the fact that the minimum supported platform for Tk-Cocoa is 10.5, which is becoming the basis for all my development, and 10.4 support will be going away in any event.

Thus, PortAuthority, Phynchronicity, and PacketStream are no longer supported on Tiger, effective immediately. The next versions of my other products will also not run on Tiger.

I'm sorry for any inconvenience this may cause to users of my existing products; feel free me to contact me by e-mail if you have concerns.

[/business] permanent link

Mon, 01 Jun 2009

Windowlist 1.1

I've been doing quite a bit of hacking on Tk-Cocoa recently, submitting a few code patches to the core developers to improve small aspects of its functionality, and also submitting patches to other projects that make use of the framework, to integrate some of its improvements. This takes some time away from commercial development, but this investment will be repaid later when my own commercial products see the improvements as well.

Amid all this work, I've updated one of my own open-source packages, windowlist. Windowlist is a package that adds a window-management menu for use by Tk applications. This update includes some code from Tom Hennigan of the aMSN team to navigate open windows with keyboard shortcuts. It also includes some changes to make it play nice with Tk-Cocoa.

While I'm proud of all the open-source work I do, windowlist is probably my favorite: it's not a complicated package, but it is solid and implements some real functionality that improves an application's usability on the Mac. aMSN and TkChat have adopted windowlist for use in those applications. I'm very pleased by that.

[/software] permanent link

Sat, 09 May 2009

simpleDND 1.1

I've released an update to simpleDND, a lightweight mechanism for drag-and-drop operations within a single Tcl/Tk application. This new release indicates a cursor change when a dragged object is hovering over a target widget--this is an important enhancement in functionality. This package will eventually find its way into many of my applications. Releasing such code as open-source is my way of giving back to the community that has helped my own work so much.

[/software] permanent link

Thu, 07 May 2009

Updates, and Tk-Cocoa

Somewhat unexpectedly, I've finished another round of updates to all my programs. I had planned to focus on new product development for a while, but a user request for some new features in Manpower prompted me to implement the features in all of my programs. It was also a chance for me to add Tkdock, the Cocoa-based icon-switching extension that I developed, to my programs; I also added a small Tcl extension that plays system alerts using the built-in sounds in OS X. All in all, a meaningful round of improvements and bug fixes.

Now that I've done these updates, it truly is time to go into R&D mode for a while. I really, really want to move my development base over to Tk Cocoa, which promises a lot of improvements to my programs, and removes some serious limitations in the Carbon-based implementation of Tk that led me to discontinue at least one application.

[/software] permanent link

PortAuthority 2.8

I've released version 2.8 of PortAuthority, my GUI for the MacPorts system of Unix software installation. This release includes better notifications of activity, such as a changed icon during a long-running process, and the use of system sounds to mark the beginning and end of activities; it also includes several bug fixes. If you use MacPorts, PortAuthority is worth a look.

[/software] permanent link

Mon, 04 May 2009

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:

  • It's easy to navigate, using a clean, two-paned interface and a toolbar. You can select various aspects of the database from the tree display on the left, and view them in the table display on the right. Plenty of Mac applications use this paned interface, for good reason.

  • There's a lot of attention to detail. The icons, while dated and ugly, are nontheless functional: they are carefully chosen to invoke the category they represent. The "Tables" icon shows a table icon. The "Indexes" icons shows an "i" icon. The "Languages" icon shows a book. And so on. It's surprising how many programs, even on the Mac, pay little attention to these kinds of details.

  • The code libraries used to build the GUI are readily available to developers, and relatively easy to learn and use. This is, perhaps, less obvious to the user, but the key libraries here are the BWidget Tree and the Tablelist table view--stable, long-running, and widely-used Tcl/Tk extension widgets.

    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

    Tue, 28 Apr 2009

    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:

  • The UI was gradually refined to better fit in with platform-specific guidelines. Colors, UI layout, icons, and visual feedback were brought in line with user expectations.

  • The speed of the program steadily improved. Previously most operations were extremely slow and processor-intensive, in part because the underlying command-line tool was slow. Wherever possible, the program was optimized/rewritten to speed up operations and to avoid calling the command-line tool needlessly. Some operations remain slow, but this is unavoidable.

  • Some modest features-such as exporting and printing log data, configuring the text display, and so on-were added. These are not absolutely critical features, but they do enhance the usability of the program by allowing the user to retain data if necessary.

    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

    Sun, 26 Apr 2009

    Phynchronicity 2.4

    Version 2.4 of Phynchronicity, my GUI for the Fink Unix software management system, is now out. In this new version, the Dock icon now changes when a long-running process (such as software installation) is active, and uses system sounds to note when a process begins and ends. It also adds some additional preference items and bug fixes. The goal is to continue to make Phynchronicity a more complete, pleasant tool for installing Unix software via Fink. If you use Fink but are confused by its command-line options, and want an actively-developed GUI with a developer standing behind it, Phynchronicity is worth a look.

    [/software] permanent link

    Tue, 21 Apr 2009

    In defense of eye candy?

    "In Defense of Eye Candy" is an interesting article about the value of attractive design in software. The most salient point:

    "The more we learn about people, and how our brains process information, the more we learn the truth of that phrase: form and function aren't separate items. If we believe that style somehow exists independent of functionality, that we can treat aesthetics and function as two separate pieces, then we ignore the evidence that beauty is much more than decoration. Our brains can't help but agree."

    In the past I've voiced some skepticism about excessive eye candy in Mac software; some Mac developers, particularly those who have been termed "the Delicious generation," tend to release programs with baroque, gaudy interfaces that tilt so far in favor of the high-gloss finish that they may sacrifice usability. If they were paintings, they would be right at home in the last Victorian era, mostly marked by decadence in its visual style.

    However, if we consider eye candy as part of a larger whole--the fusion of attractiveness and usability, with balance between the two--then eye candy is definitely important. While I've tried to avoid gaudiness in my programs, I've definitely striven for both attractiveness and usability. (An example of how the aesthetics of my programs have evolved can be found here.)

    In any event, "In Defense of Eye Candy" is a thought-provoking piece about the intersection of usablity and visual appeal.

    [/general] permanent link

    Wed, 15 Apr 2009

    PacketStream 2.5

    I've released version 2.5 of PacketStream, my network monitoring tool for OS X. This release focuses on improvements in usability. PacketStream's Dock icon now changes when a network scan is active, and uses system sounds to note when a network scan begins and ends. It also adds some additional preference items and bug fixes. If you want to leverage OS X's built-in network monitoring tools with an easy-to-use, powerful interface, PacketStream fits the bill.

    [/software] permanent link

    Tue, 07 Apr 2009

    QuickWho 1.1

    I've released version 1.1 of QuickWho, my Mac GUI for the Unix command-line "whois" utility that lets you look up domain registration information.

    Version 1.1 is a pretty significant update over version 1.0, which was a simple GUI wrapper for only the most basic functionality offered by the command-line tool. Version 1.1 offers the ability to query specific whois servers by selecting from the tree view. What's cool about this feature is that you can simply navigate with the up-and-down arrow keys on your keyboard, or use the mouse, and information for the specified domain will be returned. The command-line tool doesn't give you this ability, at least not with this ease-of-use. Also, other GUI tools don't make it this fast to navigate through multiple servers. (Apple's Network Utility tool, for instance, lets you choose multiple servers, but you have to select from a drop-down menu and hit the "get information" button each time you do this.)

    In addition to the significant enhancement in utility, QuickWho 1.1 also allows you to save and print the resulting data, copy the text, and configure the font in the text display. These were all features missing from version 1.0.

    Because QuickWho 1.1 is such a major update over version 1.0, I'm also raising the price to $24.95.

    If you do a lot of work with Internet domain registration, QuickWho is definitely worth a look--it can save you a lot of time.

    [/software] permanent link

    Mon, 30 Mar 2009

    Manpower 2.1

    I've released version 2.1 of Manpower, my man page viewer for OS X. This release adds a preferences system for managing the text display; it also includes bug fixes for the printing engine and keyboard shortcuts. If you want an easy-to-use browser and viewer for documentation on the Mac's Unix underpinnings, Manpower is worth a look.

    [/software] permanent link

    Mon, 09 Mar 2009

    What is "Mac-native" user help?

    If you are a regular user of any of my applications, and have upgraded through different versions of them, you'll notice that my system of providing user documentation has changed many times.

    I used to provide an Apple Help book (which is displayed in Apple's built-in help viewer, and is searchable) and a PDF. Then I moved simply to Apple Help. Later I moved to an elaborate hand-rolled system written in Tcl/Tk for displaying HTML, which was searchable and included a browsable tree view of the help documents. Then I moved back to Apple Help, using a Tcl extension that wrapped the most common help functions.

    When OS X Leopard was released, however, I found myself put off by the behavior of the native help viewer, which is a floating window that sits in front of every other application window on the screen. So I moved away from Apple Help, and tried putting my user help online at my website. That also presented difficulties, because what happened if there were some sort of network problem? The answer is obvious--no user help.

    Finally, I decided to settle on a simplified version of the hand-rolled help system I used a couple of years ago. This was motivated partly by my desire to develop the help viewer as a more generalized HTML display that could be plugged into an application (see tkwebview at http://www.codebykevin.com/opensource/xplat_oss.html), and also by my desire to have integrated user help without the quirks of OS X's help system. I'm pleased with the results. If you take a look at the help displayed in Apple's system below, and compare it to the help system rendered by tkwebview, they look pretty similar.

    User help in Apple's system...

    ...and in tkwebview.

    The issue, though, isn't so much how they look as how they function. The help system in tkwebview stays out of the way unless it's needed. Then it pops up in a separate window in my application. By contrast, the Apple help system sits in front of everything, getting in the user's face. I consider this a hindrance to its usability, even though it offers search capabilities that tkwebview does not.

    As with printing, I've concluded that the usability of the Tk-based system is superior that of the native help system; hence, I am using that in my applications.

    [/software] permanent link

    Sat, 07 Mar 2009

    Tk-Cocoa, at last?

    As readers of this blog know, one of my great preoccupations as a developer is the future of Tk on OS X. Tk currently is built on top of OS X's Carbon frameworks, which are more or less deprecated and will not be joining the great OS X migration to 64-bit capability. My concern has been simple: Will Tk become obsolete on the Mac if it does not run on top of Cocoa? Last year it appeared a developer was working on a port of Tk to run on top of Cocoa, which gave me great hope. But it appears that project never got off the ground.

    Imagine my surprise, then, when recently running a Google search for "Tk Cocoa 64-bit" (which I idly do, from time to time), I ran across something interesting on page two of the search results:

    das's tcl-tk at de-carbon-8-5

    What caught my eye was this phrase: "This is a port of TkAqua 8.5 to Cocoa and 64bit for Mac OS X Leopard..."

    My.What was this? Clicking on the link brought me to the main page. What awaited me there:

    " TkAqua Cocoa/64bit Port *
    * *
    * Copyright (c) 2008-2009 Daniel A. Steffen <das@users.sourceforge.net> *
    * Copyright 2008-2009, Apple Inc. *
    * *
    * See the file "license.terms" for information on usage and redistribution *
    * and for a DISCLAIMER OF ALL WARRANTIES. "

    This could scarely be better news for anyone concerned with Tk on the Mac. Daniel A. Steffen is the maintainer of Tk on the Mac--its lead developer, the one who makes sure it is up-to-date and continually improved with new features. No one knows more about Tk on OS X than Daniel. One reason I was feeling very discouraged about Tk's future on OS X is that last year Daniel had publicly ruled out undertaking a port of Tk to run on top of Cocoa. Since he works as an independent software consultant and is not paid for his maintainer work on Tk, his decision was understandable. Somehow, however, Daniel has apparently found time to work on the Tk-Cocoa project, and it appears that Apple itself is contributing resources to the project. Daniel has been conspicuously silent about his work on this project, but Apple is (in)famous for its secrecy about unreleased projects, so perhaps that's playing a role here.

    Testing Tk-Cocoa

    Out of curiosity, I downloaded the Tk-Cocoa source tree from the Github site (if you don't have the git source code control tool installed, you can download a zip archive of the source tree from the site, which is what I did). I spent some time browsing through the source code, which confirms what I hoped: this is an extensive rewrite of Tk to run on top of Cocoa, instead of Carbon. I also built Tk Cocoa from source, so I could give it a test drive.To build Tk Aqua, you should change to the source code directory in Terminal, and run these commands: make -C tcl/macosx; make -C tk/macosx; make -C tcl/macosx install-embedded INSTALL_ROOT=`pwd`/embedded/; make -C tk/macosx install-embedded INSTALL_ROOT=`pwd`/embedded/. This will build and install a standalone application bundle of the Tcl/Tk frameworks, which allows you to test the system without disturbing an existing Tcl/Tk installation. (Note: These instructions yielded a 32-bit Intel binary. I also did a test build of a 4-way universal binary: 32-bit PPC and Intel, and 64-bit PPC and Intel. I did that by exporting "export CFLAGS= -arch ppc -arch i386 -arch ppc64 -arch x86_64" and running ./configure --enable-framework from the tcl/unix directory, and ./configure --enable-framework --enable-aqua from the tk/unix directory. Running the "file" command on the resulting binaries showed a four-way universal binary, including 64-bit on both Mac platforms! I did not test that build, however.)

    What follows is my overview of Tk-Cocoa: how it compares to the current Tk implementation of Tk on Carbon, what effect Cocoa has on Tk as a development toolkit, and the larger impact for Tk on OS X. Tk-Cocoa appears to be somewhere between an alpha and beta stage right now: most of it works, but there are undoubtedly some bugs, and some of it is not yet implemented. The final release, whenever it comes, will likely improve on my reaction below.

    Improvements

    Tk-Cocoa does fix several annoying, long-standing warts in the implementation of Tk on Carbon. Images in menus is one of them. If you look at the two screenshots below, you'll see that the image in the Tk-Cocoa menu has some padding around it, while the image in the Tk-Carbon menu is smashed against the side of the menu. The Cocoa layout is the correct one. I'm not sure if this is a case of the Cocoa implementation "just working," but it certainly does work.

    Tk-Cocoa menu. Tk-Carbon menu.

    One extremely cool feature, which I discovered while rummaging around in the source code, is that Tk can now display Mac-native images. Tk had this ability on Mac Classic, but this feature has been broken every since Tcl/Tk was ported to Mac OS X in 2001. The screenshot below uses the "NSUser" system image. This feature, by itself, will make a huge difference in the polish of Tk applications on Mac OS X if it is intelligently used. (I will certainly be trying it out in my apps!)

     
    Native Cocoa bitmaps.  

    Some things, while not necessarily better, are different. The Cocoa dialog below looks very different from the Carbon. One item of note is that the Cocoa dialog does not display as a "sheet," that is, a window that slides down from the top of the main window. I hope this is functionality that will be added later, as I use this feature in all of my applications.

    Tk-Cocoa dialog. Tk-Carbon dialog.

    Tk-Cocoa also picks up the correct behavior of the "help" menu, and in fact displays something that annoys me about Cocoa programs: if the application lacks installed user help, by default it pops up a window that says, "Help is not available for this application." (Programmers should always provide user help, in my view, but that's a digression.)

    The Status Quo

    While there are some definite improvements and nice touches in Tk-Cocoa, what is especially interesting to me is how much is unchanged, at least on the surface. The two screenshots below are basically indistinguishable; both display old-fashioned Mac notebook tabs. (I'm not sure why Tk's themed "ttk" widgets use this Jaguar-era tab control, but that's been unchanged for five years now.)

    Tk-Cocoa notebook. Tk-Carbon notebook.

    Indeed, running the Tk widget demo with Tk-Cocoa, it's amazing how little seems to have changed. Most everything looks identical as before. Apart from the improvements noted above, there is almost nothing different between Tk-Cocoa and Tk-Carbon. The significance of this is clear: the goal is to preserve the user-level implementation of Tk as much as possible, even while there is a massive under-the-hood rewrite going on. It's a conservative approach, one that will not break existing packages that depend on this framework. It's a laudable goal, and one I've highlighted before in the work of other developers porting a toolkit to run on top of Cocoa.

    Rough Edges

    Of course, since the Tk-Cocoa port still appears to be a work in progress, not everything is done yet. The "to-do" list at the Github site mentions that native dialogs are not fully in place yet. Testing the widget demo, I can confirm this, as the screenshots below demonstrate.

    Tk-Cocoa color dialog. Tk-Carbon color dialog.

    The Tk-Cocoa screenshot is actually Tk's cross-platform color picker dialog, which is what Tk uses on Unix and serves as the fallback dialog on other platforms. The Tk-Carbon dialog uses the native system dialog; I assume this will be implemented at some point in Tk-Cocoa.

    Conclusion: The Significance of Tk-Cocoa

    Tk-Cocoa is a real milestone in the evolution of Tk on OS X. With better menu displays, native bitmaps, and other improvements, it offers a much higher degree of platform-specific Mac integration than it has in the past, while still preserving the API that makes Tk widely-used as a cross-platform toolkit. Cocoa purists may not be impressed, but I am definitely looking forward to using Tk-Cocoa in my applications; it will make the work I do to ensure a polished, high-quality Mac user experience with my programs much easier. I feel that Tk has always been a hidden gem, so to speak, and perhaps more developers on the Mac would be willing to give it a try now that it's moving to Cocoa.

    Fundamentally, Tk-Cocoa ensures Tk's viability as a development toolkit on OS X for years to come. Apple has been moving slowly away from Carbon for years, and finally forced the break with Carbon by not making it a 64-bit development framework. That's how Apple has ensured a convergence of all Mac developers around Cocoa. Now, Tk is no longer left behind. It joins Qt, RealBasic, and wxWidgets as a major cross-platform toolkit with Cocoa as its foundation. And it's not just Tcl/Tk applications that benefit; major applications written in Python, Ruby, Perl, and other languages will also benefit, because they have Tk bindings.

    All in all, it's a good time to be a Tk developer on the Mac. Daniel is doing a tremendous job, apparently almost single-handedly, in moving the Tk toolkit to Cocoa. And Apple, which sponsored the port of Tk to OS X back in 2001, is apparently contributing again to this important effort. I can't wait to see the final release!

    [/general] permanent link

    Fri, 27 Feb 2009

    What is "Mac-native" printing?

    As I continue to expand my capabilities with Cocoa and related technologies, I am taking a look at different parts of my applications. One of these features is printing.

    At present, I use printing in a traditionally Unix/Tk style: I write output to a temporary file, and then send that file to the printer using the command-line "lpr" tool. Tk supports generating PostScript for graphics output from its canvas widget, and simple text can be saved to a text file. These technologies provide acceptable print output from my programs. The main drawback is that command-line printing does not support Mac-native print dialogs, such as those available in Cocoa. Although I have put together a Tcl script library that presents a nice user dialog for lpr, it's obvious that it's not "native."

    It is possible to do native Mac printing in Tk. The late Mats Bengtsson developed an extension called MacCarbonPrint to provide access to Mac-native printing, using the Carbon API's. I have used this extension in my applications in the past. It allows you to take full advantage of Mac-native printing, including saving print files as PDF's, and it provides a familiar Mac user experience.

    However, MacCarbonPrint is not perfect. It doesn't handle text printing very well, which is my main need. I contributed a patch to the project that improved text printing somewhat, but it's still not ideal. More fundamentally, MacCarbonPrint is based on Carbon. It would need an extensive rewrite to use Cocoa dialogs. I've looked at the project's code base, and its size and complexity are beyond my skills at the moment.

    So my dilemma is this: what do to about printing?

    I've done more investigation of basic printing from the Mac-native API's versus using a traditional Tk approach (generating PostScript from the canvas and printing via lpr). A scientific program, SAOImage DS9, actually implements both kinds of printing in their Mac version. The Mac printer dialog is more familiar, of course, but the printed output of graphics from both printing commands is nearly identical. The main difference is the "user experience." Given, however, that MacCarbonPrint actually produces inferior text output to lpr, that takes a point or two away from the "user experience."

    On the Mac, lpr is actually a subset of the Common Unix Printing System, the modern Unix implementation of command-line printing. Apple actually owns CUPS, having acquired it a few years ago; they hired its lead developer to continue working on it, and it's still available under open-source terms. Since Apple owns CUPS, I don't think it's out of line to suggest that lpr is as Mac-native as Cocoa printing. (Like Cocoa developers, I'm taking advantage of code that has already been written and debugged by Apple engineers--in this case, however, it's Unix-oriented code.)

    In the end, for me, MacCarbonPrint is not a viable near-term solution. The amount of work required for me to port it to Cocoa, relative to the benefits of doing so, doesn't add up. Printing via CUPS/lpr produces output that equals or surpasses the Mac-native extension, with little additional work on my part. I'd rather compromise on the Mac-native dialog than give up reliable printed output.

    [/software] permanent link

    Tue, 17 Feb 2009

    How I make my Tk applications more native on OS X

    Since I'm celebrating adding Cocoa to my toolkit to improve my Tcl/Tk applications on the Mac, I thought I'd share a bit about the strategies I use to make my Tk applications as Mac-native as possible. As a cross-platform toolkit, Tk doesn't have all the OS-specific hooks that an application built in Cocoa does--but it isn't too hard to give it many of those hooks.

    Here are some questions I ask myself in trying to make my Tk applications Mac-native:

    1. Is the native functionality built-in to Tk? Before I think about extending Tk in any way, I look for functions where Tk wraps native functionality. It does so in a surprising number of ways. For instance, Tk supports sheet-style dialogs on the Mac, which is a nice touch; I use these wherever possible. Since Tcl/Tk 8.5, I can also bounce my Tk applications on the Dock with a simple command. Also, Mac-specific window flags are also there, for things like utility/floating windows.

    2. Is the functionality available on OS X from a command-line interface? Growl notifications can be called via AppleScript and osascript; no Tcl binding/wrapper needed, although one was in development at one point (and is no longer supported). Text and graphics printing can be called from the classic Unix "lpr" command; I use my own dialog box to provide visual feedback on this. It's not as native as using Cocoa printing and dialog boxes, but is adequate for what my applications require. Finally, when my programs need to execute commands with elevated privileges, they can call these commands via the classic Unix "sudo" command. (As I've written before, I use the Mac's Unix underpinnings in the same way that Cocoa developers use Cocoa functionality--as a powerful development framework.)

    3. If a native solution cannot be easily obtained, can the functionality be emulated/imitated from Tcl? Sparkle is a popular Cocoa-based application update mechanism. It lacks Tcl bindings, but I found it simple enough to develop my own Tcl package that implements similar functionality. I have also developed open source Tcl/Tk packages that implement a Mac-style toolbar, Mac-style tree and table views, a Mac-standard "window" menu, and more. If I am able to develop a Tcl script-level package that implements Mac-style functionality or look-and-feel in a way that does not seriously compromise my users' expectations, I will do that. (As well, I have developed--and discarded--some packages that attempt to implement Mac-style functionality, but fall too short of what Mac users expect.) I also use third-party script libraries like TclMacBag to implement Mac-style look-and-feel.

    4. Add compiled binary packages written in C. These can be easy to highly complex. Even at their simplest, they add overhead to building/deploying my applications. At the more complex end, they add a huge amount of complication. The dividends had be better worth it. In the case of tkdock, I felt that developing this compiled binary package was worth the time and effort. I found another library, TkCximage, in the aMSN instant messaging program; TkCximage is a powerful image library that allows image resizing. I needed this functionality for use in my help viwer and in other parts of my applications and could not find such functionality elsewhere, so I added this package to my development toolbox.

    I hope this gives you some idea of the time and effort I expend in trying to provide the best possible user experience for my programs using a cross-platform toolkit. I have invested years of work in learning Tcl/Tk; I am not eager to simply abandon that work, which has allowed me to ship five commercial Mac programs, with more under development. However, I understand the value of using Mac-natve languages and frameworks, specificially Cocoa, to extend Tcl/Tk where necessary, and I also appreciate the way the Tcl/Tk developers have already wrapped a good deal of Mac-native functionality in the language and toolkit.

    [/software] permanent link

    My first Cocoa project

    Apart from being a useful little library, Tkdock is significant for me in another way: it's my first real Cocoa project.

    Yes, you just heard the sound of hell freezing over. Yes, I've sworn up and down how much I hate Cocoa and would never learn it.

    Well. Why the change of heart?

    First, I'd say that it's only a partial change of heart. I'm still a Tcl/Tk developer first and foremost. I have no interest in becoming a full-blown Cocoa developer, using Objective-C as my development language and Xcode/Interface Builder as my development environment.

    However: there are things I can't do in pure Tcl/Tk. Things like changing the application's Dock icon while it's running. If I want to do that, I have to drop down into a different, lower-level programming language like C or Objective-C. I know I've complained about this before as well. However, after coming back to Objective-C again over the past couple of months and working through Stephen Kochan's book on Objective-C, something clicked. I finally was able to understand how compiled code worked, and how to organize code in C/Objective-C--in header files, source files, and so on. After some additional reading in Brent Welch's superb textbook on Tcl/Tk programming, I also understood how to extend Tcl at the C level.

    In other words, I finally felt comfortable trying to tackle a small Tcl extension using Cocoa (since that is now Apple's preferred development framework; Apple's Carbon frameworks are now deprecated).

    It didn't go flawlessly. I wasn't sure where to start at first, because while I felt comfortable with Objective-C and Tcl's C extension API, there was almost no sample code out there on how to combine them. (I finally found Tcl bindings for the Growl notification system; these were written in Objective-C and showed me how to call into Cocoa methods from Tcl C code.) And after I finally got started, I ran into several roadblocks with things not working as expected, with memory leaks, and with random crashes--all the things that make developing in compiled languages more complicated and slower than developing in scripting languages.

    I continued, however, and with some guidance from Daniel Steffen, the maintainer of Tcl/Tk on the Mac, I finally began to make progress. And then today, everything worked without a hitch: tkdock was ready to go!

    That's a feeling of real accomplishment. For the first time, I have built my own program in C-level code, learning as I went, understanding what I learned, and using my own code--not blindly copying and tweaking someone else's code. Some things simply can't be done at the scripting language level, and I feel proud that I'm now able to drop into a lower-level language to get the functionality I want.

    I can't say that I will replace scripting languages with Cocoa/Objective-C: my original sense that developing in Objective-C is slower and more complicated than Tcl or Python hasn't changed. But there is real power in C and its Objective-C offshoot: I can do things there that I simply can't do in Tcl (unless I implement Tcl-level functionality in C/Objective-C, as I did with tkdock). So Objective-C/Cocoa now has a permanent place in my toolbox.

    [/software] permanent link

    Tkdock 1.0

    I'm happy to report the release of tkdock 1.0, a small open-source Tcl extension that allows a Tcl/Tk application to change its Dock icon while running. This is a cool effect: it allows an application to indicate that it's in the middle of a long-running process, connecting with a server, or something similar. This package provides a nice visual touch that I plan to incorporate into most, if not all, of my applications. It can be downloaded from http://www.codebykevin.com/opensource/oss.html. There are other Tk extensions that provide similar functionality, but to my knowledge there are none that are developed as a single, simple extension package intended for general use in Tcl/Tk applications. As such, tkdock fills a void. Thanks to Daniel Steffen for his guidance.

    [/software] permanent link

    Sat, 31 Jan 2009

    New open-source packages

    I've released two open-source Tcl/Tk packages that add some needed functionality to Tk in a cross-platform fashion.

    The first package, TkWebView, provides a lightweight HTML viewer that can either be used as a standalone window or embedded in another widget. Tk is conspicuous among cross-platform GUI toolkits in lacking an easy-to-use HTML widget. TkWebView only supports basic HTML, not tables, CSS or other components of web browsers, but it still fills a void in Tcl/Tk. (An ambitious project to provide a modern HTML widget for Tk, TkHTML 3, appears to have stalled--and even when development was moving forward, it suffered from an extremely high level of complexity that made it nearly impossible to use in an application.) TkWebView could be used as a help viewer, a widget to display HTML from RSS feeds, and more.

    The second package, SimpleDND, provides a lightweight mechanism for drag-and-drop within a Tk application. There are various methods to display drag-and-drop in Tk applications, but they are either limited (quick hacks specific to a particular application or widget), complex (such as BWidgets' drag-and-drop mechanism), or not fully cross-platform (TkDND is the most powerful DND extension out there, supporting drag-and-drop between different applications, but is not supported on the Mac). SimpleDND provides basic drag-and-drop visualization with a few commands, and such fills a void.

    Both packages are available at http://www.codebykevin.com/opensource/xplat_oss.html. I hope some people find them useful.

    [/general] permanent link

    Wed, 14 Jan 2009

    In memoriam: Mats Bengtsson, 1959-2008

    The Tcl/Tk community lost an important member when Mats Bengtsson passed away in November 2008.

    While not a Tcl/Tk core developer, Mats served an equally important role: he was the author of several widely-used Tcl/Tk packages that extended Tcl/Tk in important ways, and he was also the lead developer of a widely-used Tcl/Tk application that is a model of good UI design.

    Among the Tcl/Tk packages that Mats developed or maintained are the following:

    Mats' major Tcl/Tk application is The Coccinella (http://thecoccinella.org/), a Tcl/Tk-based, cross-platform Jabber client. Coccinella is a robust application, but just as importantly, it is beautifully designed and provides a superb user experience. It is the strongest refutation possible of the old complaint that Tcl/Tk is incompatible with attractive applications. (See http://thecoccinella.org/gallery for screenshots.)

    Speaking as a Mac developer, I have benefitted enormously from Mats' work. Some of the native touches for Tk on the Mac are the result of his contributions, and his extension packages exposed powerful native API's for Tk development. Just as importantly, Mats used the Mac as his development platform, and he showed that it is possible to develop and deploy first-rate Tk applications on the Mac: Coccinella fits in very well on OS X, as it does on the other major platforms as well. Unfortunately, the Mac platform is often neglected by Tcl/Tk developers who target Windows and Linux, and Mats' commitment to the Mac was an inspiration to other Mac developers, such as myself.

    Most of Mats' projects currently lack maintainers. Coccinella, in particular, would benefit from an expanded developer base. Any interested Tcl developers should contact Sander Devrieze, another developer on the project, at the Coccinella site. (I am contributing a few patches to the project, although I lack time to take on a fuller commitment to it.) TkPath is an enormous project with many users; it would be a shame for it to become unmaintained. Some of Mats' Mac-specific projects would benefit from updating as well.

    For more information about Mats' life, please see the tribute page to him at Coccinella's website: http://thecoccinella.org/mats-bengtsson

    I hope you will all join me in expressing condolences to Mats' family and friends, and in honoring his many contributions to the Tcl/Tk community. He will be greatly missed.

    [/general] permanent link

    Mon, 12 Jan 2009

    Update cycle complete

    With today's release of PortAuthority 2.7, I have now completed updates for every one of my applications. While each product update included items specific to that application, I also focused on adding a common core of features:

    • An integrated help viewer. This replaces online help (accessed from my website) and the quirky built-in OS X help viewer.

    • Printing. I want users to be able to save data from my applications to a file, and also to print directly from my applications. The "save/export" functionality has been around for a while, but the printing has not.

    • An improved graphics engine. Specifically, this is an image display and manipulation library called TkCximage, which is part of aMSN, a Tcl/Tk-based client for Hotmail. TkCximage displays almost any image format, and includes on-the-fly resizing of images, which is useful for the help viewer and other products I have under development.

    I'm hopeful that these features make all of my applications a bit more pleasant and easy-to-use.

    With the integration of these features into my current product line basically complete, I'm also going to be focusing in the coming months mostly on development of new products. As I've discussed previously, I have a lot of ideas, and I'm eager to get started on expanding my product portfolio.

    [/business] permanent link

    PortAuthority 2.7

    I've released version 2.7 of PortAuthority, my GUI for the MacPorts Unix software management system. This release fixes a bug that caused new demo versions of the application to crash on startup; it also adds printing, an integrated help viewer, and an improved graphics engine for a sharper UI appearance. If you use MacPorts, PortAuthority is a very useful tool to have.

    [/software] permanent link

    Fri, 02 Jan 2009

    New year, new release: Phynchronicity 2.3

    I've just released version 2.3 of Phynchronicity, my GUI for the Fink Unix software management system. This version speeds up Phynchronicity on startup by reading from a cache of installed software, rather than the slower process of querying Fink's database directly; allows you to configure Fink's preferences from the GUI; adds printing and a built-in help system; and more. All in all, it makes Phynchronicity a more complete, pleasant tool for installing Unix software via Fink. If you use Fink but find its command-line options mystifying, Phynchronicity is worth a look.

    [/software] permanent link