From the Desktop: S Is For SCWM and a Whole New Scheme
By: Brian Proffitt
Tuesday, January 16, 2001 11:07:19 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reviews/2906/1/
It's pronounced "squim"
It's pronounced "squim," by the way.
SCWM has always been one of the also-rans among the X window managers. Periodically, one sees a round-up article on the various window managers, with Enlightenment, Sawfish, and maybe fwvm thrown in for variety's sake after the article's writer focuses on the Big Two, KDE and GNOME. Then, at the end of the article, there's typically a "but wait, there's more" paragraph that lists all the also-rans, but tells nothing of their features.
SCWM is not a window manager that deserves to be banished to obscurity in the X community. Rather, it deserves a very close look by those users who really want to learn how graphical interfaces are put together and who want absolute precision in how they want their windows to appear.
Some of you may be saying that you already have such things with your own window manager, and I would certainly not dispute that. But the methodology in which most X window managers approach window placement and size can be completely different from how SCWM does it.
Ready for a lesson in graphic interfaces? All nice and comfy in front of the screen? Good, here goes.
When most window managers choose a place to put a window on the screen, the size and the position of the window is determined procedurally. "This window will be put here because this is the best place, its size will be this, and the focus of the window will be that, unless this, this, or this has occurred, in which case the window will look like the other thing."
These procedures are determined by the intent of the developers who made the window manager and by the setting the user of the window manager has made in the .*rc configuration file, or the control panel interface, if the window manager has one.
Now, let it be known throughout the land that SCWM can handle things procedurally as well. In fact, most users will use SCWM in this manner, happily using all of the different window commands to shove windows willy-nilly all over the screen.
Roots in a doctoral thesis
But there is another method SCWM is designed to use, and it's right there in the name: Schemes Constraint Window Manager.
Constraints are mathematical specifications of a desired relationship. In this case, the relationship is between the size, shape, and position of windows to similar aspects of other windows, and to the desktop itself.
Such was the description I got when I spoke with Greg Badros, lead developer of SCWM, last week.
Badros, who is now the Chief Technical Architect at Seattle-based InfoSpace, originally came up with the idea for SCWM as a project for his doctoral dissertation, as he wanted to create a graphical interface using just constraints, and not procedures.
SCWM is an off-shoot of FVWM, which at the time was the most popular interface for X. Because of this, many of the procedural aspects for SCWM have their roots in FVWM practices. But, Badros emphasized, right now SCWM's closest cousin procedurally is actually Sawfish.
SCWM uses constraints in this manner. First, there are the equality constraints, which allow a user to specify aspects such as a window's width and apply that aspect to other windows. So, if a user chooses, when one window's width is adjusted, other windows' widths would also be adjusted.
Then there are the inequality constraints, where you could set up something like "this window is always to the left of this window."
The constraints within SCWM are found within a constraint-solving Guile scheme extension, Badros explained. And here lies one of SCWM's current weaknesses: it is rather difficult to build the constraint software in SCWM, which is why many users are content with the procedural aspects of the window manager.
This is a weakness that Badros definitely wants to target in the next release of SCWM. Right now, he said, he is aware of maybe two dozen people in the world who can get the full effect of constraint-based window management.
Badros also wants to integrate SCWM with the newest version of Guile/gtk. He has made the appropriate changes in his development version, but thus far has not released them to the public.
The work Badros has done for SCWM has certainly reached beyond the Linux realm; constraint-influenced window placement is clearly a part of the window placement scheme for the Help system in Microsoft's Office 2000.
SCWM is a window manager you should definitely get a hold of and really work with if you are at all interested in playing with a new method of window management. This entry curve will be steeper than most, but the payoff will certainly be worth the effort.