Thu, 17 Nov 2005
Back to Sawfish
I have been using Sawfish as a window manager of choice on all my workstation except the main workstation at work, which is AMD64 dual-head, and I had problems running it on this setup.
On Monday we have discussed with Oozy the features of our desktop environments, and I have decided to give Sawfish another try. Sawfish is an extensible window manager partly written (and configured) in Lisp (yes, those fscking parentheses :-). Since Sawfish project did not make a release in two years or so, I have decided to compile the CVS version. The packages for Fedora 4 (SRPMs and AMD64 binary RPMs) are in my FTP directory.
It works except few minor glitches (sawfish-ui crashing), and now I can have Galeon fixed at workspace 1 of the second head (metacity did not support that or it did not work in it), Liferea on Workspace 4 of the second head, Mutt window without decorations, etc. The workspace switching works correctly (unlike metacity, which has this 2+ years old unfixed bug.
I have to add an usability rant: why there are so many window manager themes with the following flaw: the focus of the window is shown only by changing the title bar (default theme in Fedora, sawfish's microGUI theme, etc.). When the window is partly obscured, it cannot be seen whether it is active or not, or even which window is active (unless you use the brain-dead approach of "the focused window is always on top", of course).
10 replies for this story:
oozy wrote: hmm Lisp :)
Oooh sawfish in Lisp, this is really interesting. I should keep an eye on it. (You know my Lisp/FP obsession ;)
Jakub Steiner wrote:
For extra crack that sawfish provides, you can look at devil's pie, a metacity companion -- http://www.burtonini.com/blog/computers/devilspie. It may have what you are looking for. Also try the Industrial or Ubuntu's Human derivate themes for metacity. We've made the unfocused windows very bland and in contrast to the colorful focused window.
Yenya wrote: Metacity
I know about devilspie - it is interesting, altough I have never got time to try it. However, binding to workspace does not work in Metacity even when explicitly set for a particular window. When I instruct Galeon to open a new tab (e.g. by clicking a ling in Liferea), it moves the whole window to the current workspace. In sawfish, it works as expected, and Galeon remains on its own workspace. Plus the two years old unfixed multihead bug noone bothered to fix. So metacity is unusable on my primary worksation.
Jakub Steiner wrote: corner case
It's good you've found a solution. I find the behavior you describe as flawed though. From the three options (move to the workspace that galeon is at after cliking a link (my dad: "where di my apps go?"), silently opening a tab in galeon without giving any feedback (my dad: "why doesn't the bloody link work?") and bringing galeon to the active workspace, the last appears to be the best choice for majority of users.
Yenya wrote: No general solution
Your dad would not pin the browser to a single workspace, of course. For unpinned windows the "move to the current workspace" behaviour is of course correct. But when user tells window manager that "this window should remain on this workspace", window manager should obey that. I am OK with either "open the new tab and switch to the Galeon workspace" or "open new tab silently at the different workspace" approaches, but "move the window that user explicitly requested to remain on some particular workspace to the different worksapce" is flawed and is directly against user's requests. It does not matter whether the user's request was wise or not, software should not try to be smarter than the user (and this is not even "smarter" like "enhance user needs", this is "do the opposite to what user has requested").
Yenya wrote: Where did my apps go?
Hmm, thinking about that -- the "where did my apps go" problem is there even with the current approach - I run Galeon in fullscreen mode, so metacity moves it on top of all other apps. If we want metacity to be "smart" (and I am not sure about that), it should not at least do this when the application that is to be moved to the different workspace is in the fullscreen mode.
Jakub Steiner wrote: pinning windows
I wasn't really aware of the "pinning" functionality. Does devil's pie provide that? The behavior you describe indeed sounds like a bug. However the pinning functionality appears like something my dad wouldn't want to worry about. It is like modding your car's chip for the extra hp. Most people just don't want to bother. I really prefer a WM that only draws the bloody window decorations and allows me to switch windows :) So I'm really happy with the approach of moving the "mod-kit" to a separate app. As for fullscreen, metacity is quite nasty for that. Gives me headaches in both blender and gimp. Unfortunately I'm not quite aware of all the aspects of the issue to file a proper bug report. I'm sure it has to do with working around gnome-panel's workarounds ;) My dad never had any window-management issues btw. Unfortunately I get a lot of Evolution questions ;)
Yenya wrote: mod-kits
I was wrong with window-pinning functionality of metacity - it was part of some additional app, (maybe devilspie). Metacity has only screen-pinning (i.e. "this window should always be on the visible workspace). As for "mod-kits" versus the "support by default" - well, why bother with more workspaces or other bells and whistles at all then? Or with other functionality like window resizing? I am all for "the app/wm should be simple by default", but not for the lack of functionality some GNOME apps seem to favour (both metacity and epiphany are excellent examples of this braindead approach). For example metacity lacks vertical maximization of windows, which can be handy for xterms - you need them to be 80 chars wide for compatibility reasons, but the height could be changed. I run mutt, slrn, and some other apps in 80x-sized terminals. Another example is firefox and epiphany - in Galeon, you can put the tabs on the left or right side, which makes the space available for the page itself narrower but higher - most pages are fixed-width anyway. Firefox however cuts off another line of the precious vertical space for the tab list, and it cannot be changed. You can then see the fixed-width web page through a ultra-wide but vertically small window, and most of the space is just filled by the page background. Fortunately, it seems that the epiphany folks are open to enhancing this browser via plugins, so we may one day see epiphany + plugins provide the needed functionality. But I don't see how plugins are different than the (disabled-by-default) support for something in the core app.
Jakub Steiner wrote: vertical/horizontal maximize
It doesn't lack the functionality actually. There's a couple of gconf keys you want to browse through. /apps/metacity/window_keybindings/maximize_vertically /apps/metacity/window_keybindings/maximize_horizontally
wrote:
Wow, thanks! When I started to use metacity few years ago, this definitely was not implemented.