Daniel Hedlund wrote: > You should be able to do what you're asking with a program called "Devil's > Pie": > http://www.burtonini.com/blog/computers/devilspie
Yes, thanks, that's what I was looking for. It's a work-around hack that requires manual setup, but it'll do for now. > "A window-matching utility, inspired by Sawfish's “Matched Windows” > option and the lack of the functionality in Metacity. Metacity lacking > window matching is not a bad thing — Metacity is a lean window > manager, and window matching does not have to be a window manager > task. As I recall, it's intentional that Metacity doesn't have window-matching, because window-matching is considered unreliable and messy. What I don't get is why when they designed the freedesktop.org standards for desktop session management they didn't address this. (Well, looking over the specs[1] it appears they haven't addressed session management yet.) I'm assuming that applications don't take on the task of saving window attributes, like workspace affiliation, because it would end up being window manager specific, or require a window manager specific API to restore the settings. But they could have designed it so the desktop manager brokered the information. Collecting a blob of attributes from the window manager and passing it to the application when it sent the "save your session" message, which the application would then save. Then on restore, the application would return the blob as part of the response to the restore session message. Similarly, why isn't there a standard for statically setting window attributes as part of the Desktop Entry[] (app.desktop file)? 1. http://www.freedesktop.org/wiki/Specifications 2. http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html > Devil's Pie can be configured to detect windows as they are created, > and match the window to a set of rules. ... > With the release of version 0.13 the configuration files changed from > an xml-based format to s-expressions. What? No GUI? I guess it's pretty easy to get working, once you figure out how to enable debugging so you can see what window attributes you are matching against. I found that 'pin' didn't have the expected effect of pinning a window to all workspaces. Instead I had to use 'stick' to stick it to all viewports. I guess there was some terminology swap between workspaces and viewports somewhere. And I saw inconsistent results from the set_viewport verb. On a desktop with 3 workspaces and a matching application on workspace 2, when I called (set_viewport 2), it put the window on workspace 3. Figuring it might be zero-based, despite the documentation saying otherwise, I tried zero, and nothing happened. I also tried set_workspace and got: ** (devilspie:8757): WARNING **: Workspace number 2 does not exist (devilspie:8757): Wnck-CRITICAL **: wnck_window_move_to_workspace: assertion `WNCK_IS_WORKSPACE (space)' failed Changing workspace to 2 Going back to (set_viewport 2), after a bunch of tests it seems random which workspace the app window ends up on. So I gave up, and tried just setting the geometry. Still weird behavior where the window gets moved to the workspace to the right of the current one. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
