[openbox] Openbox ideas, bugs and suggestions.

[Clay Barnes]

Mikael Magnusson wrote:

> 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)
>
Well, I filed the bug reports... Where do I put my scripts and rc.xml, 
menu.xml, and mapping.png files to share them?

-Clay