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

On Fri, Mar 24, 2006 at 08:42:16AM +0100, Stefan Tibus wrote:
> On Thu, Mar 23, 2006 at 04:52:14PM +0100, Anselm R. Garbe Wrote:
> > Redundancy is only good if it sucks less. I see no sense in
> > having two ways for the same functionality if one way is more
> > efficient to access - in nearly all cases - than the other
> > (because no one will use the less efficient way).
> As stated by John the less efficient way might help to learn the
> efficient way. And what I'm arguing about is that when I'm already
> working with mouse, I don't want to be forced to a "faster" key-
> driven method, as switching from mouse to keyboard makes it
> slower again (this e.g. is way there exist toolbars as "mouse-
> shortcuts"). When I have my hands on the keyboard I want to avoid
> the mouse as much as possible (and for the keyboard we have menus
> and the faster shortcuts which need some learning). Having to use
> both at a time for something that can be done with one alone "sucks"
> in my opinion.
If it sucks less having menus and toolbars, then it might be
better to have this redundancy, though I'm not sure. Actually I
noticed on my own, back in Windows days in early 90s, that my
usage patterns never got fixed to a specific way. Sometimes I
pressed Alt-S, sometimes I pressed the toolbar icon with a disk,
sometimes I searched Save in the File menu. This set of
accessing the same functionality actually hindered me from doing
an operation in a fixed way, which is equal all the time. In vim
I got used to do most of the editing stuff in fixed ways (though
vim is a bad sample for redundancy on the other hand).

> > Shortcuts scale badly once you get a huge set of functions.
> Toolbars as well. Therefore we have command lines and menus.
I think wmiimenu is a good sample for a menu which scales well
for all kinds of sets of menu entries.

> > On the other hand a huge set of functions is mostly a good
> > indicator that something is seriously wrong in such an
> > application.
> Depends on the application, think of CAD.
I got no experience with CAD applications. But my intuition
tells me, that there should be a way to design them in a very
simple way. Sometimes it is a good idea looking back 15 years
how software was done by that time, to get a key inspiration
about how to design such kind of application today in a simplier
way. During software evolution often many new features emerge
which increase redundancy drastically and no one thinks
critically about removing obsolete stuff, just for backwards
compatibility or any other reasons.

> > > > 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.
> > > On that high resolutions you can afford larger frames, but only
> > > if you really want those borders.
> > Sure you can, but to achieve the same precision you would have
> > to set the border broader than half of the client area, which
> > would mean borders of >100px in the average case.
> ??? That's exaggerated in my opinion, or what screens do you have?
> On work have 3px on 1152x864, at home 4px on 1600x1200 and a
> touchpad.
> So what's the problem with precision?
It is based on the fact, that with the current move/resize model
you use the full frame and client area and with the other model
you only use a small portion of that area. Thus the border-based
approach is simply more inconvenient to access in a precise way.

> > Move: Hold down Alt and press left mouse button, drag until you release
> > Resize: Hold down Alt and press right mouse button, drag until you release
> > (for resize the quadrant the pointer is in is used to
> > decide into which direction you resize a window)
> Where is the low learning curve here? This is simply not as intuitive
> as grabbing the title bar or border. Intuitive UIs provide lower
> learning curve and more efficient working. (Even more in lack of
> documentation.)
Be careful with intuition. The intuition you mention here is
based on the experience with Windows, OS X and many X11 window
managers which heavily follow the WIMP paradigm. If you use the
rio way or acme way the intuition you have with WIMPish
environments might be lost totally. It is more a question of
being used to some usage patterns or not and rather a question
of intuition. If you're a long-year vi user many simple-style
editors following the notepad paradigm feel very unintuitive ;)
And yes, the learning curve is a little bit higher because you
make WIMPish intuition assumptions, but in general it is even
simplier than an 8-alignment border resize approach (though it
is true that pressing a modkey to begin the action is only the
case because I can only assume a 3-button mouse, not everyone
has got 5 buttons).

> > > > just press MODKEY and move the window through the mouse grab.
> > > It saves me time by saving movements, but costs time by forcing
> > > to use both input devices at a time.
> > No only to begin the operation, and since all users are used to
> > press shortcuts it is very easy to learn.
> The argument against it is not the necessity to learn, but to move
> hands between mouse and keyboard (and not all keyboards have those
> MODKEYs for both hands BTW, and not everybody has the mouse
> righthanded).
Normally clients receive keyboard input. And normally a mouse is
a single-hand device, thus you got another hand which can be
used on the keyboard. I don't see why this is less efficient.
Even if I won't have to press a modkey to begin a resize/move
operation, at least one hand would be at the keyboard (if it is
not at my cup of coffee or at the bottle of beer).

> > Actually not. But we combine the button grabs with a key to
> > prevent accidental grabs by clients.
> Sorry, but I have no idea what these "accidental grabs" should be.
> This thing with border-based resizing is working well in many wms
> for years already...?
You cannot grab button press events in the client area for
Button1-5 because they are normally used by the client itself.
That is the only reason. Button1 is for clicking
buttons/menus/..., Button2 is for inserting text, Button3 is for
context menus and Button4/5 is for scrollbars. Thus you need to
grab a button in combination with a modifier.

> Maybe. But ever thought of non-ideal users? E.g. handicapped?
> With less precision at mouse movements? They will probably find
> your resize better than the border-based one (I have to admit that),
> but they may prefer a larger snap-value, just as they probably use
> larger borders on "classical" wms.

To prevent confusion I have to make two more general statements
to answer this remark.

First we are in Unix, and documentation of applications in Unix
world is not done through menus which may contain shortcuts or
not, but through manual pages. And I made the mistake to be a
fan of documentation in software as well, but nowadays I totally
agree that the only place where documentation should be are
manual pages.
Second we are in Unix, and we got the source of each software.
If the snap-value does not fit well, it is easy to find in the
source where it is set to be adapted to sepecific needs if there
is a non-ideal user (for snapping I doubt this really, for
style/font stuff it would be painful to force users editing the
code).

Regards,

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