[wmii] answers to IRC comments

Welcom back in IRC, Uriel,

I found following lines in backlog, but I answer them here:

> 23:13 < uriel> here is my current list of gripes:
> 23:13 < uriel> - Way to close with mouse
> 23:13 < uriel> - All mouse actions require modifiers, which totally suck and
> are unbearable in a laptop (try to hold alt while you drag the right mouse
> button on a thinkpad), this

That's a question of practice, like getting used to chording in acme. I use a
thinkpad the whole day and have no problem with holding alt while dragging. The
only problem which I can imagine occures for people with only 1 hand.

> 23:13 < uriel> requirement is absurd and the borders and tag bars are totally
> wasted areas for mouse interaction, at the very least a drag box is a must have

This has been discussed already, read the mailing list archives why we dropped
the direct mouse-only interactions (this has also todo with the upcoming
editable tagbars in wmii-4).

> 23:13 < uriel> - Resize should allow resize in any direction even after drag
started

That does not work unless you implement resizing through a reshape algorithm
like rio does (on client appearance), which is totally inefficient and most of
the time in the way and less tacit.

> 23:13 < uriel> - Allow resize by drag on borders

Get used to the current way. This is not planned anymore. Focussing a 2px
border with the pointer is much harder, than pressing Alt and performing a
resize or move.

> 23:13 < uriel> - Move tag names to sub-dir

I'm not sure about this. Actually I did this sometime ago, but misliked the long paths:

/views/foo/sel/sel/ctl

compared to

/foo/sel/sel/ctl

Though I have in mind to remove /view and doing everything in /tags/<tag> with
/tags/sel, but this is a wmii-4 issue, and a quite unimportant detail.

> 23:13 < uriel> - Grabmod must die

No, there are several people using Mod4 for beginning move/resize with the
mouse.

> 23:13 < uriel> - Incorrect focus when sending window to managed from float

I can't confirm, if I send a managed window to float, it has still the focus.
If not then there might be a bug.

> 23:13 < uriel> - 'Swap' useless, focus should remain in previous location

No. The current behavior is more atomic. If you want to achieve the behavior
you ask for: change your Swap-Key handler in wmiirc as follows:

MODKEY-Control-$LEFT)
        xwrite /view/sel/sel/ctl swap prev
        xwrite /view/sel/sel/ctl select next;;
MODKEY-Control-$RIGHT)
        xwrite /view/sel/sel/ctl swap next
        xwrite /view/sel/sel/ctl select prev;;
MODKEY-Control-$DOWN)
        xwrite /view/sel/sel/ctl swap down
        xwrite /view/sel/sel/ctl select up;;
MODKEY-Control-$UP)
        xwrite /view/sel/sel/ctl swap up
        xwrite /view/sel/sel/ctl select down;;

Though note, that swapping will be removed after the release, because it is
unnecessary.

> 23:13 < uriel> - Duplicated swap-up/down keybindings

This has been disucssed already, read the mailinglist archives.

> 23:13 < uriel> - No way to grow/shrink col or window from keyboard?!?!?!

There are no default shortcuts to do such things, we prefer mouse-based
resizals, because the mouse is the better device for resizing/moving. Though in
the mailinglist archives you will find ways, how to achieve keyboard-based
resizals.

> 23:13 < uriel> - To start a new client in a new view requires 3(!) steps: 1)
> Start client in current view *yuck* 2) Retag client 3) swap to that view

Sure, what do you expect? If a tag does not exist yet, a view can't exist for it.
Though you can define a rule in /def/rule to tag specific clients automatically,

e.g.:

/Firefox.*/ -> 2

This rule tags firefox always with "2", and safes you from retagging a client.

> 23:13 < uriel> - All larswm-like functionality (including swaping (something
> that always have been half broken in wmii), automatic col creation, and cycling
> (something wmii has never ma
> 23:13 < uriel> naged to do) is missing, broken, or unuseable (whoever said
> swaping worked exactly like in larswm either was stupid, lying, or had never
> used larswm)

This is not larswm. Read the mailing list archives to look for reasons why the
larswm model cannot be applied to column layout without adding a bunch of
unnecessary complexity. If you use column layout for quite a long period of
time, you will find new usage patterns (very acme-alike ones btw), which make
swapping unnecessary.

See the swapping-removal discussion for details in the archives.

> 23:13 < uriel> if any of them is factually incorrect, I would like to hear
> 23:14 < uriel> I certainly dont feel like having any pointless argument with
> garbeam about any of this shit

In several details you expect different functionality or usage patterns in wmii
without respecting the existing ones.

> 02:27 < uriel> about keybindings: I refuse to change the defaults, if the
> defaults suck so much that are unusable, they should not be the defaults
> 02:27 < uriel> 2) the problem is not to have to type it two times, the problem
> is that you have two lists of items to keep in sync, which can create all kinds
> of hard-to-debug errors
> 02:28 < uriel> it is just too error-prone

I'm not satisfied with the way it is, but after having considered all kinds of
alternatives, it is the least sucking way so far, in wmiirc. See the mailing
list archives for details.

There are advantages and drawbacks with border-based mouse-only resizals, with
title-bar based movements etc. Same with modifier-key introduced ones. And one
can argue pro- or contra to these things, same with your expectations with
swapping, or your valuable proposals for re-arranging the fs interface.

In the end it is a question of personal tasted and usage patterns, but you
didn't used wmii-3 long enough yet, that I can respect your criticism about its
current user interface.

Regards,

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