[judge]

What's it all about?
I like to think of it as active objects - icons that respond to their environment rather than just sit there.

• It allows non-programmers to develop docklets and desklets. You do this by composing the 'icon' out of overlay images and by tying those images to a set of meters that cause the overlays to change.
  
• It also allows script writers to write docklets and desklets with more functionaility than the existing meters and overlays can provide
  
• Finally it provides a way for C++ coders to write docklets and desklets that work on ObjectDock, YzDock and AveDesk - I was also going to write my own standalone application like AveDesk to host SysStats configs, but there's probably not much point now with AveDesk.

I did all this because I got tired of using Samurize for some things, DesktopX for others and individual docklets for yet more stuff. I also got tired of what I percieved to be major shortcomings of those programs - namely that they didn't allow script writers to get full access to their object model.

So I wrote my own.

What configs are available for SysStats?
The biggest collection is at DockEx. There are also many here at AquaSoft that are designed to primarily be used with AveDesk. Remember - you can use configs listed for YzDock and ObjectDock in AveDesk too.

If you develop configs for SysStats - don't be shy - share them. Upload anything that will work on ObjectDock to WinCustomize and DockEx. Upload anything that is intended only for AveDesk to DockEx (which basically means that it is too big to display well in a dock - remember configs will work in ObjectDock, YzDock and AveDesk).

Why would someone write a C++ plugin for SysStats
Rather than, say a desklet or a docklet? After all, isn't that like writing a plugin for a plugin?

Well. If you write something that can be used as an overlay or as a meter you're giving other people a chance to use it in ways that:

• You didn't envision
  
• You don't have time to do yourself

If you want to write for SysStats - look at how other configs work, read the help files (there are two - there's a hyperlink for the script help file somewhere deep in the main help file) and download the SDK.

So what's the philosophy behind SysStats?
I'm a big believer in design patterns in software development. In particular of MVC for use in GUIs. SysStats tries to adhere to that design pattern: Overlays are Views, Meters are Models and (in the next release) Controllers will be Controllers. The advantage of this pattern is that it ensures that the purpose of a component is very clear and that the interface to each type of component is well-defined. This in turn means that modders can combine the various meters, overlays and controllers in novel ways without having to understand how each one works and without having to get down-and-dirty with scripts and plugins.

There are many other places in SysStats where I could allow users to configure how it works (thanks to careful application of other design patterns) and there are many other ways in which I could improve its integration with Windows (courtesy if COM), but unless I can make it pay big bucks, that's not likely to happen.

About the only thing I would like to see improved is the editor - which is just a bunch of dialogs ATM. Samurize has a clear edge here.