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

On Thu, Mar 23, 2006 at 03:43:05PM +0100, Anselm R. Garbe wrote:
> 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.
So the ideal limit is: number of code lines = 0 ;-)
 
> > 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).
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.

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

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

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

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

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

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

> > 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).
I prefer CAD by keyboard commands and use the mouse for snapping
only...

> 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.
That's true.

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

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

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

Regards,
Stefan
Received on Thu Mar 23 2006 - 16:17:09 UTC