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

On Thu, Mar 23, 2006 at 04:16:35PM +0100, Stefan Tibus wrote:
> On Thu, Mar 23, 2006 at 03:43:05PM +0100, Anselm R. Garbe wrote:
> > Removed code is debugged code.
> So the ideal limit is: number of code lines = 0 ;-)

At least 0 LOC means no bugs.

> > > 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).
> I don't like it to judge user's being complete fools and this
> is going into that direction. There don't have to be hundred's
> of ways to do things, but it's not generally bad to have more
> than one. A certain (though minimal) amount of redundancy is
> good.
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).
A bad sample for many redundant ways for the same functionality
is vim (remember :help registers). And having redundant ways,
also means having a higher learning curve (btw. I don't agree
the thesis 'Usability simply does not equal low learning curve'
of Tuomo. As Stanislaw Lem pointed out, genious ideas are
always simple. And a high learning curve means that the
underlying paradigm is complex and everything else than genious,
and redundant ways are a good indicator for complex concepts).

> > 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).
> I don't agree on this. In the example with the toolbar, I'm forced
> to get the hands of my keyboard, which interrupts my work flow.
> Shortcuts are the fastest way, and menus help if I don't remember
> the shortcut or the pictogram I have to look for and can be
> driven by keyboard or mouse.
Shortcuts scale badly once you get a huge set of functions.
On the other hand a huge set of functions is mostly a good
indicator that something is seriously wrong in such an
application.
Though, I agree that shortcuts are often the most efficient way.
But for the question of resizing/move, you only access the mouse
in conjunction with pressing the MODKEY to perform such an
operation in a precise, flexible and efficient way.

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

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

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

> > 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.
> As I'm not sure what those tagbars will be and how they work,
> I can't tell. But moving by click and drag is most intuitive.
That is the current way, except that you start moving with
pressing Alt.

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

> > 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).
> See above, I really missed it. But my mouse has three buttons (some
> have five), do I really need (clunky) help from my keyboard then?
Actually not. But we combine the button grabs with a key to
prevent accidental grabs by clients. I'll add a way to configure
both shortcuts, then you will be able to define mouse only
ways for the functionality (though X actually only knows 5 mouse
buttons and not more, regardless if you got a mouse with 200
buttons or not).

> > > 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.
> Hmm...I prefer a minimal amount of choice, or why is wmii configurable
> after all?
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.

> That's yours. See above on stripping menus and shortcuts for
> toolbars... and e.g. CAD programs without command line interface
> are ugly to use (unless you have a good sketchboard), while you
> can't strip defining points by mouse. There are too many commands
> to have them all visible in toolbars and then one ends up with
> subtoolbars etc. etc. Yet, menus or toolbars are great if you
> temporarily don't remember that command.
Sure, toolbars don't scale well, but that is another kind of
discussion. (IMHO toolbars are also an indicator of bad UIs).

Regards,

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