[openbox] OB3 important missing human-interface feature!

Clay Barnes clay.barnes at gmail.com
Fri Jun 23 18:43:59 EDT 2006

On 03:45 Thu 15 Jun     , Clay Barnes wrote:
> Well, depending on your interest in user-interface theory, it is
> either a good or a bad thing that my 1200+ word (first half) treatise
> on OB3-related human-interface design was totally hosed.  I'm pretty
> upset, but C'est la vie.  I'll compose such things in seperate
> files and just copy into mutt next time.
> Let's start by assuming you have just read thousands of words on why
> keyboards are a fundamentally better means of interacting with a
> properly-designed window-manager (than a mouse), and that my arguments
> were so brilliant and insightful that you wouldn't question my opinion.
> I'll do my best to earn it, have no fear, but for now, I'll just give
> the abbreviated spiel.
> There are a very limited number of reasons that a user moves or resizes
> a window: 1) make more space inside an application, 2) make space for
> another application, 3) reveal another application, 4) (less common)
> make less space for an application to overcome bad UI design that makes
> a large space to sparce 5) (very rarely) a few misc. reasons that are
> not relevant for the vast majority of users with any frequency.
> To this end, designs like ratpoion, wmii, ion3, and the like are close
> to optimal, but suffer serious the serious flaw of *requiring* maximal
> effeciency of space use (which is often not preferred or comfortable
> for end-users).
> Now, to address the need for a window manager to permit the maximum
> effeciency of operation, there is a single, very accutely missing
> feature (and no, it's not a tile windows command---though it would be
> helpful, it's not nearly as critical):  resize window to next edge.  The
> command takes the specified edge of the active application and moves it
> to be adjcent to the first edge it finds, either screen edge or
> application edge.  This addresses the increase application size concern,
> in that now a user can create a window, move it (using rough, large
> increment skips mapped to four keys on the keyboard), and in a few
> keystrokes (usually 4) fill exactly the desired space.
> This brings to mind a serious flaw in the resize system:  it only works
> with the south and east edges, which can be overcome with a move+resize,
> but that fails to work with windows that resize by characters (terminals
> and many plain-text editors like gvim (and xemacs?)).
> I've a lot more detail to add, but It's about 4am here, and the car
> needs to be taken to the shop at 7ish.
> Incidentally, if I sounded cocky, I was just being flippant, and my
> apologies.  Excuse the quality of writing and spelling, too.
> --Clay

Well, there seems no official word on the list about a timeline for the
inclusion (if it's been accepted) of this feature into OB3.  I consider
it among the higest priority additions, but I'm highly opinionated
(don't get me started on MacOS!), so I guess I'm not really the only
person who needs to be consulted.

I know, I know.  Before someone tells me to code it myself, I already
thought of that, and my C/C++ skills are simply too old and rusty (I'm
trying to get them back up to par!) to do anything but taint the
codebase.  Plus, I'm totally new to WM programming, so I've a lot of
learning before I'm ready to patch a WM.  I have another idea, though:
instead of doing the coding, I could take care of other OB3-related
tasks that would otherwise occupy someone who could write the patch.
I am certainly capable of documentation (end-user or code), code
cleanup, or other monkey tasks that need doing.


More information about the openbox mailing list