5

Metacity: Window matching experiment

view full story
linux-howto

http://blogs.gnome.org – At the Collabora party, someone from Canonical (if it was you, raise your hand) 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. (Software)