Openbox ideas, bugs and suggestions.

Clay Barnes clay.barnes at gmail.com
Thu Aug 4 17:23:03 EDT 2005


I've been using OpenBox for about four months. I went from KDE (ugly, 
and not flexible enough), to Gnome (very advanced, but crufty as hell), 
to XFCE (just plain ugly, unnatural, and bloated), to Blackbox (terrific 
UI, small, but very inflexible), to FluxBox (same great UI, plus tons of 
flexibility), to... drum roll... OpenBox! OpenBox was everything I 
wanted: no unnecessary components, excellent UI, and total flexibility. 
I know that bit seems like a waste of space, but I am actually getting 
to a point. Anyway, every one of these window managers had their 
strengths, and through my wide experience with them (the start with KDE 
was 1999), I hope to add a few ideas to the OpenBox project that other 
projects benefit from.

The one feature that sticks out as missing in OpenBox is the lack of the 
'arrange windows' (resize and move windows to fill screen) command. 
Every other window manager (except excessively minimalist BB) has this 
feature, and OpenBox would really benefit from its inclusion. When 
implementing this feature, handling of maximized (horizontally, 
vertically, and both) windows would be tricky. I would highly prefer 
that handling be specifiable by the user. Three levels would work well.
* In the first level, windows in any maximized state would not be 
resized (but can be moved) in the process of trying to re-arrange the 
windows. If no space is available for windows, or if less than a 
user-specified (by percent) area is available, no action should take place.
* In the second level, windows that are only vertically or horizontally 
maximized are not toggled away from that state, but are resized along 
the resizable dimension (to give all windows equal area), and maximized 
windows are untoggled from maximized state, and they (along with other 
non-maximized windows) are resized to fill the remaining space. If both 
vertically and horizontally maximized windows exist in the same 
workspace, the group with the most windows (either vertical or 
horizontal maximization) remains maximized, and the other group is 
untoggled and treated like un-maximized windows. If both groups have 
equal numbers, the group with the highest windows keeps the maximization 
toggle. (One method to determine which group has higher windows is to 
sum up the positions of the windows from top to bottom and let the lower 
totals have priority. (i.e. (from top to bottom) for windows like the 
following, vertical maximized window (+1), normal window, horizontal 
maximized window (+3), vertical maximized window (+4), horizontal max 
window (+5), vertical maximized windows have a lower total (5) than 
horizontal maximized windows (7), giving vertical. maximized windows 
priority)).
* In the third level, all windows are unmaximized and resized as equals.
In the latter two methods, all windows should be resized to establish 
equal area for each window, and with the first method, all resizable 
windows should be resized to establish equal area of the available area.
I know this is a big spec, but I tried to minimize the ambiguity of what 
I described and do a little preliminary condition/error handling logic 
for you.

Second feature suggestion: Is it possible to make the slit totally 
invisible (as an option)? I hate having to close all my open slit apps 
or move the layer the slit is in because I'm watching a dark movie and 
there's a white line in the edge of the frame.

Bug report: I noticed that the move to E/W/N/S edge commands do not 
always work (more often than not, my windows just jump to that edge of 
the screen. If you want, I'd be happy to try to nail down exactly when 
the command works correctly.

Last feature suggestion: I have a very extensive set of keybindings 
(about eighty-eight keys/mouse buttons/events are bound to over a 
hundred and fifty events), and so far, aside from the bug above and this 
problem, they've worked wonderfully. I see one major shortcoming in the 
system, though. When I want to resize a window to the North or West, I 
have to call a resize plus a move. This works fine in most cases, but 
character-size resizing windows (like gVim and xterm) present a problem. 
The chain calls for a resize of, say 20, plus a shift of 20. In these 
cases, the window resizes 20 characters (say 500 pixels) but only moved 
20, so I have a slightly shifted, greatly resized window that is too far 
to one side. Actually having commands to resize from any side would 
completely solve this problem.

I would also like to contribute my (very extensive) rc.xml and a .png of 
the bindings therein to the project as a started file for people new to 
OpenBox who want to see a more extensive use of the capabilities that 
the window manager offers.

-Clay Barnes



More information about the openbox mailing list