Almost everything we bind keys to could be done with an external application via EWMH, and on my computer there’s no perceptible speed penalty. (I’m sure there is on slower machines.) Perhaps there should be a configure switch not to include the code to do everything except the things which pop up switchers (and another switch not to include those, in case you use superswitcher) and then we could supply a separate executable for people who’d turned them off, so that pressing the “move to workspace right” key actually did “metacity-move –right” or something. Maybe it would reduce the memory footprint on faster machines. Maybe on the other hand it wouldn’t be worth the trouble.
Photo © Telstar Logistics, cc-by-nc.
I’m trying to think through the advantages and disadvantages of this idea.
On the pro side, Metacity become smaller and simpler and (presumably) more easily maintainable, while it becomes easier for third-party tools to integrate with Metacity and we get a handy command-line tool that can manipulate any EWMH-compatible window-manager.
On the con side, all the extra code from Metacity would just wind up in another executable, and all keyboard operations would gain the ‘spawn a new process and connect to X’ overhead.
Given that one can already disable Metacity’s standard keybindings, and that one can already configure Metacity to launch arbitrary programs with an arbitrary keypress, and that libwnck is so easy to use for messing with EWMH messages, I expect Metacity might as well keep doing what it already does unless consumer demand becomes audible.
Spawning new processes is very slow when your machine is under heavy load. Depending on external applications for the most basic functionality is asking for problems.
You have to make sure a typical “rescue my laptop from load 50” scenario (switch, raise, minimize windows, switch desktops, push windows to other desktops) does not require spawning any new processess. We don’t want to cause an avalanche.