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

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.

> Shortcuts scale badly once you get a huge set of functions.
Toolbars as well. Therefore we have command lines and menus.

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

> > That's somewhat true. But shortcuts for maximization (x,y,both)
> > or corner alignment are very useful.
> That is true. But I don't think that we need shortcuts for such
> functionality, because they only would work in the floating
> layer, which we only got to handle WIMPish or broken apps in an
> adequate way.
Well. We have to deal with them, so I want efficient ways to deal
with them.

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

> > > Thus I favorize the quadrant-based
> > ...looks like I missed that feature. Where is it documented?
> Dunno if it is documented well.
> 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.)

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

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

> We only want options whenever they are necessary. Ie. I found a
> good way to calculate the snapping value dynamically based on a
> golden ratio value, thus I have been able to remove /def/snap in
> hg tip. Reducing the options to a bare minimum which is really
> necessary is good, because the art is to get ideal defaults for
> everyone (though that is not possible for style stuff etc.
> because everyone has a different taste, but it is possible for
> many usage patterns). If there is no option, people don't ask
> for an option, at least I noticed this.
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.
 
> (IMHO toolbars are also an indicator of bad UIs).
...just as menus, shortcuts... - we end up with no UI at all ;-)

Regards,
Stefan
Received on Fri Mar 24 2006 - 08:42:48 UTC