Re: [wmii] wmii-4 fs proposal/discussion

From: Kris Maglione <bsdaemon_AT_comcast.net>
Date: Mon, 12 Jun 2006 03:53:44 -0400

On Mon, Jun 12, 2006 at 09:40:40AM +0200, Anselm R. Garbe wrote:
>On Mon, Jun 12, 2006 at 03:25:27AM -0400, Kris Maglione wrote:
>> On Mon, Jun 12, 2006 at 09:18:19AM +0200, Anselm R. Garbe wrote:
>> >I don't agree with any exception for floating clients. We have
>> >move [+|-]<x> [+|-]<y> and resize [+|-]<w> [+|-]<h> as commands
>> >for clients in wmii-4. That works with both (floating and
>> >managed clients). The move might be ignored for managed clients.
>> I absolutely disagree and I've thought the current behaviour has been
>> broken from the start. I don't like to think as columns as a bunch of
>> clients and I don't like to have to pick some random client when I want to
>> resize a column. If anything, I'd set the height by client, but certainly
>> not the width.
>
>I can live with either way. But your approach with
>distinguishing columns from clients is different from what
>happens if you resize a managed client with mouse... That is
>client-driven, thus I decided to also make the
>kb-driven interface to be consistent with this behavior.
>Anyway, it might be fair to differentiate between the
>kb-interface and mouse-interface in this question for managed
>clients.
To be honest, I've never been happy with the mouse behavior either, but I've
never had a better idea that was worth replacing it with, other than the
obvious one of grab boxes, which *should* also treat columns as columns.
Nevertheless, I'd be happy with the discrepency, because it is so obvious and
natural for the fs to work this way that I can't overlook it.

>> >Also note, that we already decided how to replace the column
>> >modes, see the TODO. However I think having a command for the
>> >view namespace to set n visible clients for the current
>> >column is no big deal.
>> Just to clarify, who's we? In every discussion I've
>> participated in on IRC, the proposal in the TODO is
>> universally disliked.
>If Uriel doesn't likes it, it does not mean that it is
>universally disliked. 'We' is me and the majority of
>IRC-visitors (as well as list members due to discussions).
Yes, but I'm not uriel's henchman. Only one conversation where it's come up
has involved uriel and he said about 5 words. In the last one, I believe that
sleepydog brought it up. You can grep the irc logs if you'd like.

>> I can think of several ways of achieving the effect of
>> multiple collapsed clients and the one in the TODO is the one
>> that I like least of them all. I'd be *much* more comfortable
>> just being to collapse a client to 0 height and being able to
>> split the height of a client with the one above or below it.
>> It seems to me that the suggested behaviour, on the other hand
>> would be, though simple, absolutely unbearable.
>
>The approach being proposed in the TODO reduces the interaction
>work of the user to basically navigation. Your approach looks
>cumbersome compared to the automatic behavior of the
>TODO-approach. I don't want to define specific heights pro
>managed client, that takes too much time.
>
>The idea behind the TODO approach is, that the stacking behavior
>is polished somewhat more, and it will even reduce switching
>modes for most users. Depending on the screen height 2 or 3
>visible clients pro time will make the maximization quite
>unnecessary and rarely used...
That's not the point. The point is that the proposal is unweildy. I don't want
the middle n clients visible at once and I certainly don't want them to cycle
when I want to show another window. I never said anything about defining an
exact size, I said it might be nice to collapse the current client, or split
the space, but I'd also be ok with just having a binding to collapse the
current client and uncollapse the one above/below it. The defined automatic
behavior, though, just seems absolutely terrible in terms of usage, even if it
does 'reduce the interaction work of the user'.

Sorry, I'm tired and I'm rambling. The point that I'm trying to make is that
the proposed behavior is of almost no use to me. I'd be much more likely to
have three groups of windows in a column, all of which I'd like to have 1 of
visible at once than 5 random windows that I'd like to have three of a row in
visible at once. Ask any die hard acme user which behavior he'd prefer. I
*know* wmii isn't acme, but acme is the only setup I know of that is even
remotely comprable where you have an actual userbase to draw from.

-- 
Kris Maglione
find: missing conjunction
Received on Mon Jun 12 2006 - 09:54:17 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:09:05 UTC