Currently Konfabulator can be downloaded from konfabulator.com as well as widgets.yahoo.com. The Konfabulator site contains a developers' section called Workshop. Here you can find the reference guide, a simple tutorial, and a Photoshop template, as well as some other tools.
Here is the current URL:
Here's what the Konfabulator web page says about the product:
When you install the product, you'll be able to run the widgets, either as part of your normal desktop (as opaque topmost windows, or normal application windows), or you can place them exclusively on a sort of second desktop (called Konsposé), which can be switched on and off with a hotkey. The "Konsposé" mode is my favourite, as I can get these widgets out of view when not needed, and I can quickly pull them to front when I want to use any of them. Each widget is actually a separate process, which runs its own interpreter instance.
Does it make sense to use this tool? The need for these mini applications is certainly questionable - after all, I am able to get the information displayed within them from various desktop applications or websites. In my opinion, the centralized access, and the attractive visuals alone are worth the memory footprint. We don't need plants in the office, and we don't need a personal coffee mug in the workplace - however having them makes our environment more bearable and colorful, and they add a personal touch to the otherwise gray environment we're spending too much time in.
What sort of functionality is best delivered as a widget? In my opinion, these are some of the key attibutes of a widget (as opposed to a fully functional desktop application or webpage):
The widgets should do one specific thing instead of having multiple functional modules hosted within the application - if the user needs to navigate within the application a lot, the whole quick on-and-off aspect of the widget and the hosting Konsposé view is lost
The user input should be minimal. The environment has rich presentation functionality, but there are no pre-built form based components to deal with radio buttons, dropdown lists, validated, complex user inputs. A normal desktop or web based application has a richer suite of existing input controls.
The widget should display a limited amount of information, especially textual information. The desktop space is limited, and a large widget looks out of place between the small, graphic-heavy widgets. A more useful approach is just to highlight the key elements of whatever information is available for the particular functionality within the widget, preferably with images, not just words, and to open up the full application or web page on demand when the user wants to dig in.
Once you decided the functionality of the widget, the actual implementation is straight forward, with a very simple programming model.
To have your own widget, first you need to create a new directory with the widget's name (for example, HelloWorld.widget). Below this root directory level, there should be a Contents directory.
The key resource in the widget's Contents directory is the actual widget definition file, which should have a .kon extension (example: HelloWorld.kon). This .kon file is an XML document, so it's a good idea to configure your editor to treat .kon files as XML documents.
Unfortunately there's no DTD or XSD for the XML format. There's a message on the support forum where the developers note that they do intend to deliver this later on. I guess the ownership of Yahoo! will also move the platform into this more strict direction, for example to reduce support problems for widget writers.
Each .kon file is somewhat like a HTML page. There's an empty canvas for your widget, but it's fully transparent unlike the white background of a browser page. Each file contains one widget. Each widget can contain windows drawn onto this transparent canvas.
The section above defines an input box (the Konfabulator type is textarea) in the window. The attributes of the component are defined using CSS-like attributes, but the engine itself does not support CSS-like separation of components and style attributes, you have to define colors, fonts and style for each element separately. It'd be great to have support for a separate CSS file, or at least reusable CSS class-like style definitions, as it'd make styling easier and cleaner. Currently it takes a lot of copy and paste to change the look of the widget.
For the actual layout and position mechanisms, I recommend to read the The Beginning Widget Writer's Guide.
The general flow of a widget execution is the following:
The last section of the widget definition file describes the various configurable properties of the application. The preferences panel is the available for each widget with some default attributes. Additional attributes can be added to the main preferences panel, or custom tabs can be added to contain more structured preferences. There's no extensive persistency framework included with Konfabulator, however these attributes are automatically persisted in the registry.
After completing your custom widget, you can package it (following the detailed instructions in the Konfabulator documentation), and publish it in the Widget Gallery hosted by Konfabulator/Yahoo. There's a widget available which prepares the zip archives, but I couldn't resist my "enterprise development" "repeatable automated build" tendencies, and I've created a batch build file, which uses an XML parser to check if the .kon file is well-formed, then zips it with the free InfoZip tool.
@ECHO OFF set WIDGET_NAME=FXHistory set INFOZIP_PATH=c:\work\zip set XERCES_PATH=c:\work\xerces %XERCES_PATH%\PParse .\%WIDGET_NAME%.widget\Contents\%WIDGET_NAME%.kon IF ERRORLEVEL 1 GOTO ValidationError %INFOZIP_PATH%\zip build\%WIDGET_NAME%.widget -r .\%WIDGET_NAME%.widget GOTO End :ValidationError @ECHO Validation Error :End @ECHO Build finished