Introduction
This is the first in a series of journals I plan to write about the evolution of DesktopX into version 3.
So let me give you a background on this because some people may think "Why so much written stuff on this thing? What's the big deal?"
DesktopX has traditionally acted as an environment where people could put objects on their Windows desktop, and then combine them together to either design a complete desktop or as a mini-application and then export them as a desktop (a DesktopX theme) or as a program for others to use (a widget).
The reason why widgets are such a big deal is that since the Macintosh was released in 1984, we've only had to two types of "things" that would show up on your desktop. You have icons, which are just little static pictures. Or you had full blown applications. There was nothing in between. They either were full blown programs or they were just pictures.
I don't normally toot our horn too much on this issue but because some other programs have tried to imply they somehow came up with this concept, DesktopX was the first program to actually deliver on the concept of having interactive content on your desktop that could be created by end users.
The idea for this isn't new. IBM, Apple, and Microsoft all wanted to have something that was more than an icon but less than a full blown program. Something that could exist on your desktop that wasn't much harder to create than an icon and was a lot less complicated to make than a traditional application.
Centralized Scripting
In DesktopX 2, a widget developer would create several objects on the desktop and then attach bits of scripting to each one based on what they wanted it to do. This made it easier to create fairly simple widgets but more complex ones were a bit of a pain because DesktopX 2.x couldn't really create new objects.
That changes in DesktopX 3. In DesktopX 3, you can control everything in your widgets from a single script. One place this makes things easier is in terms of dealing with user input. In DesktopX 2, the object being clicked on was the object that had to handle the input. This could be a pain in the butt. DesktopX 3 lets callbacks be in the same script.
So let's say you have a widget with several buttons on it. Each button is an object. In DesktopX 2, each object would have to have a script to deal with what happened when the user clicked on that button. In DesktopX 3 a new API exists:
function Object_OnLButtonUp(szObjectName, x, y, bStatus)
{
}
So now you just supply the object name and you can handle its inputs from a single script.
