- It’s done so late to avoid the effect of another piece of code which attempts to resize the window; it was a quick hack. I will move it back.
- Good idea; there may be prior art in Metacity since we have (or used to have) something to stop ordinary new windows appearing on top of one another
- Okay; I’ll do this last since it would stop me testing with (say) xlogo.

I’ve made a list of what needs doing and what I’ve done here; I’ll work on this over the next few days.

Tried it today, some feedback:
- A matched window can be seen moving from the default position when it is opened.
- Opening two windows with the same role will cause them to open at exactly the same location. I would expect the second window to open offset from the first (e.g. like the windows calculator does)
- Only match using WM_WINDOW_ROLE. Many applications dynamically change the name of their window (e.g. gcalctool sets it to the current mode). It is better to patch the applications that should be using a role and leave applications to explicitly not have a role if they don’t want to be matched.

- workspaces: saved as part of the position, so windows restore to the workspace they were left on.

- offset bug: saving the frame position, restoring the client position. If we use the frame for both, it shouldn’t matter too much if the user changes theme. I suppose it might put us a few pixels off at worst; do you think we should both save and load the client window position?

A bunch of questions:
- About the workspace stuff what are your plan ? makes the windows position depends on the workspace it’s launched on, or save the workspace as a part of the windows position (which means that the same application will always be launched on the same workspace) ?

- For the current windows offset bug, are you saving the frame or client window position ? and also what will happens if a user changes his theme ? (because in that case the frame size will probably change)