Konfabulator’s Missed Opportunities
In my post Dashboard and Konfabulator I said I disliked Konfabulator because it has a weak programming model. Defenders of Konfabulator may claim that comparisons to XUL or HTAs, both of which predate Konfabulator, are unfair and miss the point. As a pragmatic person I can sympathize with the argument that a tool is good if it meets a need. Nevertheless I found the programming model in Konfabulator to be dissapointing. It’s not my intent to slam Rose and Clarke and their work on Konfabulator, but I do want to highlight some missed opportunities.
Konfabulator 1.0 was released in February 2003. Now, a little over 16 months later, Konfabulator is at Version 1.7. Over that time there have been modest enhancements to its programming model.
strings on the Konfabulator executable and searching in the Konfabulator Forums.) At the heart of a Konfabulator Widget is a
.kon file. A
Many Konfabulator Widgets are essentially web service clients. As there is no XML support in Konfabulator, SOAP and XML-RPC are not supported. Konfabulator provides a synchronous
URL.fetch() method but asynchronous operations can only be performed by shelling out via the
Konfabulator has been said to be highly extensible. That’s true in the sense that a stone is a versatile base for soup. Following the same analogy the most valuable aspect of Konfabulator is the community that has embraced it.
I didn’t attend WWDC 2004. What I know about writing a Dashboard gadget/widget comes from Dave Hyatt’s Surfin’ Safari.
The WebKit based programming model behind Dashboard’s widgets is broad and deep and too important to be relegated to Dashboard only. James Duncan Davidson discuss Mac OS X as a “pragmatic platform.” That gives me hope that WebKit based apps will become a viable choice for desktop development.