I noticed a neat product called Konfabulator which lets you create small 
desktop "widgets" that get placed on the desktop and display information 
downloaded from the web (see http://www.konfabulator.com). You can use 
Konfabulator, for instance, to create a little widget on your desktop 
that displays the local weather, or a shot of the traffic from a web 
cam. There a lot like WindowMaker/NextStep tiles, but of arbitrary shape 
and size. And Konfabulator provides a simple way to make widgets using 
JavaScript. Each Konfabulator widget uses its own system process that 
takes up (usually) around 4-8 megabytes of memory.

Are there any takers out there for adding the following to Spoon:

1. Change the VM so that the window displays without a window frame, ala 
Konfabulator. Allow for transparent portions of the display (also ala 
konfabulator).
2. Have the ability to display text and images with hotspots. The mvc 
framework is enough of a UI for allowing the user to alter the applet's 
preferences.

That's it.

Since it's Spoon, you've got the Flow already built in for downloading 
images and data. So the technical aspects of this don't seem overly 
ambitious. Just with the framework above, most Konfabulator widgets 
would be quite easy to do. An optional FFI-type package could be 
provided for the class of applets that monitor other programs and system 
attributes (ie. The ITunes trackers, the wifi reception gauge, etc).

Of course, there's already an app that does all that -- Konfabulator. 
But by starting with Spoon, you could probably get little applets to run 
in just a couple megabytes each, beating Konfabulator. Startup and 
execution speed would be faster. Small devices could be targeted. And 
Konfabulator costs $25. Of course, the scripting language would be 
Smalltalk. All good reasons for an applet developer to choose a 
Spoon-based konfabulator.

There have been all kinds of attempts to jump start parcelling of the 
image. But it might be a good idea to expend a little bit more energy 
into approaching things from the other direction, and start small. As I 
understand it, that's the point of Spoon. This just adds a clearly 
defined target application (a squeak Konfabulator) which might provide 
some clarity and impetus for the initial development of packages/modules 
for Spoon. The developer that wants a simple zip tool would port the 
zip/archiving classes. The developer that wants a slide-show widget 
would port the ImageReadWriter classes. Someone might want to replace 
MVC with a compact and skinnable widget set for deployed apps. You get 
the idea.

So is it worth trying?