[openbox] Openbox ideas, bugs and suggestions.

[Mikael Magnusson]

On Thu, 4 Aug 2005, Clay Barnes wrote:

> 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.

hi

> 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.

You should add this to the bugzilla if you want it to not disappear.

> 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.

What movie player do you use that doesn't set _NET_WM_STATE_FULLSCREEN 
correctly? Any such app appears above the dock and panels.

> 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.

I'm assuming here they don't resize the window if the window is in fact 
not resizable. Maybe they shouldn't move to the edge if they can't be 
resized since it's inconsistent wrt n+w/e+s.

> 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.

Also bugzilla this (separately).

> 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.

Feel free to do this.

> -Clay Barnes

--
Mikael Magnusson

ps
sorry for my lack of eloquence which i am known for (the lack, that is)