[openbox] OB3 important missing human-interface feature!

[Manuel Colmenero]

El jue, 15-06-2006 a las 03:45 -0700, Clay Barnes escribió: 
> 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.

I guess I get what you mean. I use the keyboard for windowing stuff all
the time. Yeah, I believe you, no need for further explaining :P

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

Agreed.

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

Yup.

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

Whaa? I'm resizing here towards the four edges. Maybe I misunderstood
you, or whatever. But I think you can do it. Am I missing something, or
do I have to give up smoking crack?

Have a look at rc.xml. Here's mine:

  <keybind key="A-1">
	<keybind key="Left">
      <action name="GrowToEdgeWest"/>
	</keybind>
	 <keybind key="Right">
      <action name="GrowToEdgeEast"/>
	</keybind>
	<keybind key="Down">
      <action name="GrowToEdgeSouth"/>
	</keybind>
	 <keybind key="Up">
      <action name="GrowToEdgeNorth"/>
	</keybind>
  </keybind>

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

yeah, I'm sorry for my spelling too.

Cheers.