[openbox] OB3 important missing human-interface feature!

Mikael Magnusson mangosoft at comhem.se
Fri Jun 23 19:03:12 EDT 2006

On Fri, 23 Jun 2006, Clay Barnes wrote:

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

Either you or me is really slow, what is wrong with the growtoedge* 

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

Mikael Magnusson

More information about the openbox mailing list