Re: [wmii] snap: 20060323 -- mouse support

On Thu, Mar 23, 2006 at 03:18:01PM +0100, Stefan Tibus wrote:
> Hmmm...I don't think it's good to resolve problems by removing
> features which are suffering from these.

Removed code is debugged code.

> But there are other arguments against it as well:
> Why is it better to only have one way to do things?

It is ideal to have only a single way for each feature and not
plenty ways. For example the WIMPish environments have menu
entries, shortcuts and toolbars connected to the same function
often. This is annoying, because it forces the user to choose
between several usage paths (and often users aren't able to
fixate their usage patterns because of this choice of usage
paths). If the user hos no choice, this not only keeps the
concept simple and less complex, it even makes the usage more
efficient. The point is only to make such functions accessible
in the most efficient way (which means for the WIMPish paradigm,
that if you got a toolbar item, no one will use the same
function from a hidden submenu entry or hardly to remember
shortcut, because the toolbar item is the most efficient way to
access such function, thus dropping the hidden submenu entry
would be good polishing of such an application).

As for resizing/moving windows in wmii, the current way is the
most efficient. Keyboard driven movements/resizals lack
efficiency, because of the missing snap-to-border feature, and the
annouying rough move/resize steps. That is the reason why there
are no default shortcuts for keyboard driven resizals. Not
to mention that keyboard driven movements/resizals are very slow
(wether you need modes like in wmii-2.x or you have clunky
shortcuts in the end).

The border-based way for resizals/movements lacks efficiency,
because it is not convenient to target a 3px border in large
resolutions to resize a frame. Thus I favorize the quadrant-based
resize and move approach first seen in pwm/ahwm. It is even much
more efficient than the menu-driven 9wm or box-driven twm approach
(which are quite similiar).

Also, soon we get tagbars in frames, thus Button1 for moving
frames won't work (at least not without unprecise grabbing
boxes) - thus the modkey based approach is straight-forward.
You can resize without mouse (for mouseless environments), but
mostly people got a mouse and then it is used in the most
efficient way. The pointer is nearly always in front of the
client area, thus you can even safe the time to move the pointer
to the titlebar or anywhere else to just move the window, you
just press MODKEY and move the window through the mouse grab.

> I like the possibility to move and resize windows by keyboard
> because I don't have to get my hands off the keyboard just
> for doing so. (BTW, I'm missing defaults for this in current wmii.)
> But sometimes I'm already working with the mouse and then I don't
> want to have to mess with the keyboard. And those combinations of

Computer work is mainly keyboard-driven, even in image
manipulation apps you need the keyboard to add mouse modes (ie
for drawing lines with 45 degree angles or resizing rectangles
with correct scaling, see the Gimp or Photoshop for instance).
There is no computer environment without a keyboard, but
sometimes there are environments without a mouse, thus depending
on keyboard or keyboard and mouse devices for resizing is no
problem and will work in nearly every scenario.

> mouse buttons and keys are really ugly... Remember the Apple
> mouse with the single button and that ugly emulation of additional
> buttons via the keyboard!

Maybe you didn't got used to the current way. Personally I'm
using it for months (I never used the inefficient border-based
approach so far).

> Just as it is not good to force users to use the mouse I think
> it's not good to force user's to the keyboard. X is a mouse

I force users to use the most efficient way we/I found out
during the years, assuming only default input devices.

> driven environment anyways. Well designed applications are
> supposed to have keyboard bindings for menus, buttons, etc.
> so one can do all the stuff in two ways. And if other window

I can't agree. Those apps are bad designed from my POV.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361