Sugar should track window property changes

[bert]

The Sugar-specific window properties currently must be set before opening the activity window, otherwise Sugar mistakes that window for a raw X app. This is difficult with many window toolkits that create and open a window in one go, with no chance to intervene. Activity authors are resorting to terrible hacks to work around this. Much better would be if Sugar tracked window property changes on open top-level "raw" X windows, so if an activity opens the window first and then sets the Sugar properties, it will still be recognized as an activity.

[AlbertCahalan]

Tracking property changes to implement the GUI simply can't be reliable. You have a race condition, and maybe even a (mild?) security problem.

The UI needs a mild redesign anyway. There are problems (bugs in trac too) with killing activities that don't start, timeouts (which will always be both too long and too short), and even just chewing up CPU time with the throbbing icon.

Starting the icon throb early is no good; there are alternate animations that could work. (example: icon flies up behind the donut, then comes through the hole if it shows up on the X server) For local connections on DISPLAY=:0.0, X can get lots of info about the client. It should do so, if it doesn't already. It should provide this info to sugar, if it doesn't already. That's enough for sugar to identify the client without needing racy cooperation from the client. For remote connections, things are fairly raw... but you can still ask for an icon (scale it as needed) and name.

[cscott]

We should be using the freedesktop.org startup-notification-spec: http://www.freedesktop.org/wiki/Specifications/startup-notification-spec