At the Collabora party, Robert Ancell asked me how difficult it would be to implement window matching in Metacity. I decided this was an interesting question and spent an hour and a half today working on it. The results are now in the matching branch in GNOME git. If you’d like to download it and give it a try, please feel free.
It currently saves configuration data in a keyfile which contains one group per window, in this format:
[xlogo]
x=287
y=178
w=250
h=231
This isn’t necessarily how it will end up: we could use GConf or perhaps some database-like format. It uses a modified version of the system suggested by Hongli Lai: if WM_WINDOW_ROLE is set, we use that to recognise the window, otherwise we use the window title– otherwise programs like xclock wouldn’t be matchable. The role or title is currently represented by the group name in the keyfile. The keyfile is saved at ~/.cache/metacity/matching.conf.
The system stores the position and size of every window at the moment it was closed. There is no need to edit configuration files by hand.
There are inevitably some caveats:
- There is a bug such that when windows are restored they are offset by the size of the top-left hand corner of the frame. (In other words, the coordinates are misinterpreted as the client window’s position, not the frame’s.)
- I haven’t tested this for scalability at all. Keyfiles might be very inefficient when you have hundreds of records for all I know.
- It doesn’t know about workspaces, and it should; this will probably be the next thing I add.
- If your window was minimised or maximised, this will not be restored, and it should be. This will probably be the next thing after that.
- It might not be the best idea to write out the keyfile on every window close. Probably better to keep it in memory until the WM exits.
- It might be useful to have a switch on the window menu to lock the position and size so it restores the same way when you reload it, in case you move it. On the other hand, this sounds like crack.
Should this branch be merged when the bugs are ironed out? Should it replace WM-based session files? These are good and interesting questions and ones we should discuss. Tune in next time, gentle reader! Or better, comment below.
Photo © Bob Fornal, cc-by-nc-sa.
It’s an interesting new feature that will probably make a lot of sense in mutter.
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)
@Oliver:
– 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?
Hand up, that was me.
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.
These are all good points:
– 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.
It’s really great to read that somebody is working on this – thank you so much.