Shallow Thoughts : tags : window managers
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Mon, 20 Oct 2008
Someone on #openbox this morning wanted help in bringing up a window
without decorations -- no titlebar or window borders.
Afterward, Mikael commented that the app should really be coded
not to have borders in the first place.
Me: You can do that?
Turns out it's not a standard ICCCM request, but one that mwm
Mikael pointed me to the urxvt source as an example of an app that uses it.
My own need was more modest: my little
Xlib program that draws the moon at approximately its current phase.
Since the code is a lot simpler than urxvt, perhaps the new version,
moonroot 0.4, will be useful as an example for someone (it's also
an example of how to use the X Shape extension for making
[ 12:06 Oct 20, 2008
More programming |
permalink to this entry |
Sun, 17 Jun 2007
It was a bit over two years ago that I switched
icewm to fvwm as my window manager. Fvwm proved to be very fast,
very configurable, and "good enough" most of the time. But lately,
I've found myself irritated with it, particularly with its tendency to
position windows off screen (which got a lot worse in 2.5.18).
It looked like it was time to try another window manager, so when
I learned that the Openbox
project is headed by a fellow
or, I had to try it.
Openbox impressed me right away. I'd tried it once before, a couple of years
ago, when I found it a little inconsistent and immature. It's grown up a
lot since then! It's still very fast and lightweight, but it has good
focus handling, excellent window positioning, a good configuration
window (obconf), and a wide variety of themes which are pretty but
still don't take up too much of my limited screen space.
But more important, what it has is a very active and friendly
community. I hit a couple of snags, mostly having to do with focus
handling while switching desktops (the problem that drove me off
icewm to fvwm), so I hopped onto the IRC channel and found myself
chatting with the active developers, who told me that most of my
problems had already been fixed in 3.4, and there were .deb files
on the website for both of the distros I'm currently using.
Indeed, that cured the problem; and when I later hit a more esoteric
focus bug, the developers (particularly Dana Jansens) were all over it
and fixed it that same day. Wow!
Since then I've been putting it through its paces. I have yet to see
a window positioned badly in normal usage, and it handles several
other problems I'd been seeing with fvwm, like focus handling when
popping up dialogs (all those secondary GIMP Save-as dialogs that
don't get focused when they appear). It's just as flexible as fvwm
was when it comes to keyboard and mouse configuration, maybe even
more so (plus it has lots of useful default bindings I might not
have thought of, like mousewheel bindings to change desktops or
"shade" a window).
I was going to stay out of theme configuration, because there were
several pretty good installed themes already. But then in response to
a half-joking question on my part of whether a particular theme came
in blue, someone on the IRC channel made me a custom theme file -- and
I couldn't resist tweaking it from there, and discovered that tweaking
openbox themes is just as easy as fiddling with its other defaults.
I don't use transparency (I find it distracting), but my husband is
addicted to transparent windows, so when I noticed on the web site
that openbox handles transparency I pointed him there. (He's been
using an old Afterstep, from back when it was still small and light,
but it's been a constant battle getting it to build under newer gccs.)
He reports that openbox handles transparency as well as afterstep did,
so he's switched too.
I haven't looked at the openbox code yet, but based on how fast the
developers add features and fix bugs, I bet it's clean, and I
hope I can contribute at some point.
Anyway, great focus handling, great window positioning, fast,
lightweight, super configurable, and best of all a friendly and
helpful developer and user community. What more could you ask for in a
I'm an openbox convert. Thanks, Dana, Mikachu and all the rest.
[ 14:13 Jun 17, 2007
More linux |
permalink to this entry |
Mon, 13 Dec 2004
I've been alternating between icewm and openbox for my window manager,
but I'm not entirely happy with either one. They're both fast to
start up, which is important to me, but I've had frustrations
mostly relating to window focus -- which window becomes focused when
switching from one desktop to another (icewm's biggest problem) or
when a window resizes (openbox), and also with initial window positioning
and desktop location (e.g. making one window span all desktops without
having to select a menu item every time I run that app).
Someone was opining on IRC about fvwm and its wonderful configurability,
and that made me realize that I haven't really given fvwm a chance in
a long, long time. Time to see if I was missing anything!
The defaults are terrible. No wonder I didn't stick with fvwm after
newer windowmanagers came out! It's definitely not an install-and-go
sort of program. Nor is the documentation (a long and seemingly
thorough man page) clear on how to get started configuring it.
Eventually I figured out that it looks for ~/.fvwm/config, and
that some sample configs were in /usr/share/doc/fvwm/sample.fvwmrc
(which is a directory), and I went from there. After several hours
of hacking, googling, and asking questions on #fvwm, I had a setup
which rivals any window manager I've found: it's fast, lets me configure
the look of my windows, lets me bind just about anything to keys,
and seems pretty well behaved focus behavior. More important,
it also allows me to specify special behavior for certain windows,
for example, making xchat always occupy all desktops:
Style "xchat" Sticky
which is something I've wanted but haven't been able to do in
any other lightweight window manager. That alone may keep me
in fvwm for the forseeable future.
Tips for things that were non-obvious:
Rotating through three desktops
In other window managers, I define three desktops, and use ctrl-alt-right
and left to cycle through them, rotating, so going right from 3 goes to
desktop 1. fvwm has both "pages" (a virtual desktop can be bigger than
the screen, and mousing off the right side scrolls right one page) and
desktops. I didn't want pages, only desktops, so
turns off the pages, and it was clear from the man page that
PointerKey Left A CM GotoDesk -1
would go left one desk (the only unclear part about that is that A
in the modifier list means "Any", not "Alt", and "M" (presumably for
"meta" means alt, not the windows-key which some programs use for meta).
"PointerKey" is needed instead of "Key" because otherwise fvwm gets
confused when using the "sloppy focus" model (the man page warns
The question was, how to limit fvwm to three
desktops, and wrap around, rather than just going left to new desktops
forever? The answer (courtesy of someone on IRC) turned out to be:
PointerKey Left A CM GotoDesk -1 0 2
PointerKey Right A CM GotoDesk 1 0 2
PointerKey Left A CMS MoveToDesk -1 0 2
PointerKey Right A CMS MoveToDesk 1 0 2
The only problem at this point is that MoveToDesk doesn't then change
to the new desktop, the way other window managers do, but I'm confident
that will be easily solved.
I had the hardest time getting buttons (e.g. maximize, close)
to appear on the titlebars of my windows. You'd think this would
happen by default, but it doesn't. It turned out that titlebar buttons
aren't drawn unless there's a key or mouse action bound to that button,
which they aren't by default. So to get buttons for window menu,
maximize, and close, I had to do:
Mouse 1 6 A Close
Mouse 1 8 A Maximize
Mouse 1 1 A Menu Window-Ops Nop
But then showing buttons 6 and 8 (the even buttons are numbered
from the top right) automatically turns on 2 and 4 (I chose 6 and
8 because their default shapes were vaguely mnemonic), so they have
to be turned off again:
Style * NoButton 2
Style * NoButton 4
Smaller titlebar and window frame
I also wanted to reduce the titlebar height and the width of the window
frame: I don't like wasting all that screen real estate. That, too,
took a long time to figure out. It turns out I had to define my own
theme in order to do that, then add a couple of undocumented items
to my theme. There's lots of documentation around on how to make
buttons and background images and menus and key bindings in themes,
but none of the documentation mentions simple stuff like titlebar height.
+ TitleStyle Height 16
+ Style "*" BorderWidth 5, HandleWidth 5
+ ButtonStyle All -- UseTitleStyle
Style "*" UseDecor MyDecor
New windows should grab focus
Most window managers do this by default, but fvwm doesn't, and requires:
Style * FPGrabFocus
Full config file
For any other settings, see my
fvwm config file
[ 18:14 Dec 13, 2004
More linux |
permalink to this entry |
Mon, 09 Aug 2004
Searching, as always, for the perfect window manager ...
Helix likes ion3, because it handles key accelerators very well,
so I thought I'd try it.
I don't really like the "tiled or fullscreen" model it uses by
default, but found the answer in the FAQ (after a rude RTFM comment
which made no sense, since I already had RTFM and it doesn't give
information on anything but runtime arguments): press F9 and get
it to prompt for the type of the new workspace (the correct answer
is the one with "Float" in the name).
All of the available themes use the "small grab handle around the
title, but the rest of the titlebar isn't there" look. I don't like
that (it's harder to find a place to grab to move windows around)
though I suppose I could get used to it. Not a big deal.
It does look like it has good key binding support, and ways to
specify different behavior for different apps, both of which would
be very nice. Focus behavior on resize seems to be the same as openbox
and icewm, though: if the window resizes out from under the cursor,
it loses focus. Also the root menus (right-click) are a pain: they
don't stay posted, and they're small, so it's hard to navigate them.
I'm sure ion3 has some coolnesses, but I decided that it didn't look
likely enough to solve my problems to be worth learning how to
configure it (and that unjustified RTFM left a bad taste in my
mouth about how easy that configuration was likely to be). So
I'm back on openbox for a little while, anyway.
Here's what I want out of a window manager:
- First, startup speed and basic operation comparable to icewm or openbox
(my two faves so far).
- Intelligent handling of keyboard focus even when in "focus follows mouse"
mode. That means:
- When switching workspaces, focus goes either to the window
under the mouse, or the window on that workspace which last
had the focus (either one would be fine). Openbox does this
pretty well; icewm's focus is pretty random.
- When resizing a window that has focus, it should keep the
focus even if it resizes out from under the mouse.
- Click in a window focuses (but doesn't necessarily raise) that window.
(Again, openbox does this well, icewm doesn't.)
- A new window or dialog gets focused.
- A way of setting up rules for different windows:
e.g. I want xchat to be on all workspaces, or I want moonroot to
come up with no window borders. I shouldn't have to do a
right-click-and-menu-selection operation every single time I
- Easy configuration to start apps with from a menu on the root
or via key bindings (or, ideally, both). No dependance on
having a panel (which was why I quit using xfce4).
Both icewm and openbox handle this well.
- A way of navigating among windows using only the keyboard.
Both openbox and icewm allow for easy movement between
workspaces and moving windows between workspaces, but in both
of them, alt-tab toggles between the current app and the last
app on that workspace, and there seems to be no way to get to
anything besides those two.
[ 18:36 Aug 09, 2004
More linux |
permalink to this entry |