* networked applications could show when they're disconnected
* editing programs could show if there are documents to be recovered
* downloading/transferring programs (like BitTorrent) could show a progress bar (or bars)

I would not go as far as allowing interactive elements (like play/next/etc. buttons on a music player) since these would interfere with the icon's main function, plus such things are more like full-blown applets/widgets/screenlets.

A nice benefit of this approach would be the ability to display a large amount of information completely in context (ie. only the information relevant to the displayed icons will be shown)

This could be accomplished using completely animated icons, but the stackable quality of emblems would be more desirable and would require less effort.

Aside from being very useful and incredibly cool, this could offer applications an alternative to abusing the notification area with perpetual icons. Instead they can add functionality to any of their panel launchers. The advantages would be that the icon will be there even if the application is closed, users can move around each icon individually and that the panel already has all of the infrastructure for adding and removing icons, taking that responsibility away from the applications.

PS: Extra special points for doing it in a standardised way for potential cross-platform/desktopness :)

http://lkcl.net/pyjamas/pyjamas-xpdom.tgz

by utilising web browser technology as a desktop widget set, i and many developers have found that web browser technology makes a better desktop widget set than desktop widget sets make desktop widget sets.

the reason is quite simple: browsers have had far more attention put on them, far more man-decades of time put into them than the desktop widget sets have (and you can confirm this by looking at the statistics calculated on ohloh.net)

browser technology provides event management (just like desktop widget sets do) and much much more.

browser technology as a desktop widget engine is _drastically_ undervalued, thanks to its association with javascript. however, it turns out that if you "take away" the javascript by using compiler technology such as Google Web Toolkit, RubyJS or pyjamas, you actually have a stunningly powerful cross-platform applications development environment.

the pyjamas widget set API is the world's _only_ free software cross-platform, cross-browser, cross-desktop, cross-widget-set development environment.

now.

let's extend that a little further: what can you do with it?

well, thanks to pyjamas, you can write a desktop window manager in python in about 300 lines of code. if you have an NPAPI plugin which allows you to pull up a window containing a command (which does exist - it's in xorg and it's called xrx but it needs a little work) then you can write a desktop window manager in python that can be compiled into javascript, to run in all major web browsers _and_ also run "native" on the desktop.

how can you run an NPAPI plugin in a desktop app? well, because you're using webkit as the engine, webkit supports NPAPI plugins, so you can stick _anything_ into the desktop app - flash plugins, java plugins, mozplugger - anything that's NPAPI compliant.

problems (which can be overcome): xrx is unfortunately using XNest to run the remote command embedded in the web browser. XNest has had an extra run-time parameter added to it where it can take the X-windows "parent id" that it is supposed to attach to. in this way, the Xnest instance can embed _itself_ into the x-window frame that xrx creates for it.

however, Xnest is pretty much the _only_ x-windows command that has this option, and no other x-windows-capable command (certainly not any KDE commands and certainly not any Gnome commands) can "self-embed" like this.

mozplugger, which is another NPAPI-compliant plugin that attempts to shoe-horn some 140 different commands into an embedded browser window, has a _really_ ugly solution to this problem.

what they do is they fire up a "monitor" process which looks for the process id of the command being run, and it dicks around in the x-windows process space, finds out the commands' x-windows id and slams it into the parent window frame.

looking through the source code of mozplugger, it's specifically documented that occasionally this process can go horribly wrong, and the job of the "monitor" is to keep an eye on the app to make sure that it doesn't "pop out" of the embedded NPAPI frame!

there's a better solution: use python-xlib and python-plwm as the basis to write a dedicated window manager that performs this job.

yes, this is the title of the solution, finally coming through.

what you do is you make the webkit-glib app the "root" window: as you're going to be writing a window manager in python, this is ok.

the NPAPI plugin will fire up a frame in the browser technology, and the python-based window manager code, because it receives all X-Windows events, will know that this has happened.

etc. etc.

you might recognise this solution:

* in microsoft terminology it's called "active desktop"

* in palm's terminology it's called "WebOS", their new effort to create a new mobile smartphone operating system based around webkit

so it's not a new idea, it's just a free software way to make it happen.

and, as warbo points out, it's incredibly powerful. anyone can write a bit of javascript and run it on their own desktop. thanks to language bindings (either through XUL/Gecko or webkit-glib/gdom

* Automatic GError integration with JavaScript exceptions. You leave the GError argument out of your arguments, and internally Seed passes it in to the method, and throws an exception with the proper name and message if an error is generated.
* Some "syntactic sugar" which makes code more pleasant to write, such as JSON key/value pairs for constructor properties, literals for structs (stage.color = red: 200).
* Ability to define new GTypes which inherit from existing GTypes. As of now you can not implement abstract methods, but beyond that it works. Signals and properties work.
* A C module system, useful for binding libraries which are not GObject based (such as readline, sqlite, and many low level POSIX functons).

At this point, the vast majority of the GNOME platform is usable from Seed.

In general using any GObject based API (internal to your application, or a library) in Seed, should not be difficult, and should simply require a few changes to your build scripts to allow generation of the introspection data.

There is a writeup on Seed which I believe provides a good description. [http://arstechnica.com/open-source/news/2009/01/javascript-gtk-bindings.ars]

--

Adding new features to this tool you can develop applications and games with ease. Even a person without much knowledge of programming can develop in JavaScript. It is a very powerful and simple language, especially combined with the features of Webkit.
A good way to start is by supporting the SeedKit (http://live.gnome.org/SeedKit) to create rich interfaces using HTML5, CSS3 and JavaScript. Technologies on the rise at the time and used for various applications, including the iPhone itself.

(If you want these options then you must know what they mean, which makes you a power user and thus more suited to a different distro)