[openbox] OB3 important missing human-interface feature!

[Clay Barnes]

On 01:03 Sat 24 Jun     , Mikael Magnusson wrote:
> 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* 
> actions?
At least on my box, they grow to the edge of the screen, not to the next
application edge.  Is this a bug, or the intended use?
> 
> >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