Re: [wmii] summary of some #wmii talk on 2006-03-02

On Fri, Mar 03, 2006 at 12:30:19PM +0100, Uriel wrote:
> On 3/3/06, Anselm R. Garbe <garbeam_AT_wmii.de> wrote:
> > The concept is still dynamic, even much more dynamic and
> > acme-like than the larswm concept.
> > You got 3 kinds of column arrangement, stacking, maximized and
> > equal (like larswm's tiled stack). If you need to concentrate on
> > a specific client, you maxmize it in the column, if you want to
> > check a different client, you can check with stacking for its
> > title or with equal for its contents on the fly. If you want a
> > client in another column, you just send it to the specific
> > column (prev, next, or numeric beginning at 1).
> > That is already all about it. It is _not_ like larswm, but it is
> > very similiar to the acme approach.
> This is all complete nonsense, nothing of the things you mention here
> implies that automatic column creation should not work just fine.

I never argued that it would not work fine, I argued that it is
unnecessary complex.

> And let me tell you, acme col management _sucks_ (actually, works well
> for the somewhat limited context in which acme works, acme is after
> all not a general purpose wm and you rarely fiddle with cols.)

Why? As usual, no justification...

> > In the old concept, once a column got destroyed, and another one
> > created, I often had to fix the column widths, that was a very
> > frking task all the time. With allowing empty columns this is
> > gone now.
> More nonsense, a way to easily and fast col resizing is needed anyway,
> so this should be a non-issue, and really, it should be trivial to do

I began writing wmi, because resizing my clients manually all
the time sucks. Why should resizing cols all the time sucks
less?

> because cols can only be resized along the x axis, so all you need is
> a grow operation(maybe a shrink one, but that can be emulated by going
> to the neighbour col and growing it, just as individual windows are
> managed in a single col)

That was not the point. The existing resizing is easy to
achieve, but it makes rarely sense to resize again and again if
columns disappear from time to time.

> > Exclusive flag is not simplier, it is just the special case
> > capacity=1 for the general case.
> Generality often implies extra complexity, and in this case for no
> good reason at all.

The code would be the same, if you check nclient > 1 or nclient
> capacity, both might have the same impact.

> > 1. You have two kinds of maximized clients in a column which you
> > cannot easily check.
> WTF? There is a single kind, the exclusive bit has no effect on the
> client itself. It only kicks in when you try to add a new client to an
> existing col.

Still there are two different ways to achieve client
maximization.

> > Is a client maximized in a column or is the
> > column itself exclusive?
> WTF does this have to do with exclusive? You could as well have a
> single client(non-maximized) in a column and it would look the same as
> a maximized client in a col with more clients. (Easy solution, change
> the color of the grab box for maximized clients)

A single client attached to a non-exclusive column is not the
question. The question is if a second client is attached. Then
you have two ways to get defacto-maximization with different
impacts. In acme there is only one way.

> > 2. Once you dynamically create/destroy a column, the width of
> > the other columns is destroyed, this is very nasty often.
> Of all the issues you list, this is the only one marginally valid, and
> as I explained above, it should be a non-issue, also it should not be
> hard to keep track of the previous column layout and restore it when a
> column is added. (Eg., if you delete the 3 col, and then it's created
> again, you keep track of what was the width the last time you had a 3
> col, this can admittedly get messy, and maybe it's not worth doing,
> but anyway you need a fast way to resize cols, so who cares?

Well might be a minor issue, agreed.

> > 3. If you have set all columns to exclusive, where do you create
> > a new column? Just right of the current one, or most-right?
> Just pick one, IMHO most right makes most sense and is probably
> simplest to implement.

Assumed that the adjacent column is exclusive as well this will
be messy. Despite of the fact that such exclusive flag is
something like locking (like we got rid in frames), the main
question is not that a new column is created implicitely or not,
the main question is, how does the zooming works. In the way I
proposed like it is in acme, it is totally easy, just set a
column into max mode and all clients are maximized if you cycle
through the attached clients. Here, with an exclusive column you
would need to define how to bring other clients to it,
sendtoarea next (and there is a exclusive flag'ed column) would
be interesting what happens. Does the selected column gets
destroyed and its client is pushed rightwards, the right column
pushes its client rightwards as well, because it is exclusive?
If the selected column is not destroyed, where does it gets the
other client from (assume the adjacent column is exclusive as
well). Does it grab a client from rightmost column, which might
be column 4? Where is the requested predictability?

I think you haven't thought enough about all the impacts.

> > 4. If you kill the client of a exclusive column, do you destroy
> > the exclusive column or do you try to fetch the client from the
> > adjacent column? If adjacent, what do you do, if it is set
> > exclusively as well...
> Ok, this is a more interesting case, but I can't see why it should be
> hard. To have pure-larswm behaviour, yes, I suspect you need to try to
> grab a client from the right if you run under one client. But still if
> you didn't do this and you would just kill the window, dynamic col
> creation still would be worth it.

It is possible to find a way, but either way will be more
complex than necessary. See the other issue above.

> > I think this are only some issues I yesterday encountered, there
> > might be even more. And you can easily guess that this gets very
> > messy in the code. Especially sucking was the 1st point, because
> > you got two different ways for the same, and that is bad design.
> I can't see any reason why code should be messy to implement, the
> concepts are very simple and clear. And the 1st point was the most

Then enlighten us about the simplicity and clarity in the
concepts. I don't think they are that clear and simple, because
I have thought about it quite a lot already. And believe me, I
know now why LarsWM consists of two columns only. I also
understand why acme is like it is. Because it is easy to
understand. Well assumed you would use column layout like in
LarsWM it wouldn't be too hard to be implemented, but assuming
you allow more columns it gets tricky'er.

> lame and pointless of all, exclusive and max are totally independent,
> exclusive just means the wm enforces having a single client on this

As I pointed out, you missed the point.

> > That is true. But your idea is not approved yet to be implementd.
> > If the current concept is kept, the empty CN event is only for
> > updating the client title in the bar (though I'm convinced that
> > we don't need to display the client title in the bar anymore).
> Holy fuck, not more "update titlebar" script insanity! I thought we
> were over with that crap.

There is no update titlebar script. But if a client title
changes wmii produces CN <new title> as event which can be read
from /event and used in scripts. The main event loop writes the
argument to /bar/2/data, this simply displays the client title
in the bar. Nothing else.

> > I don't favorize the larswm concept anymore, I get too used to
> > acme already. And see the other points above.
> Acme is certainly nowhere as dynamic as it could be(and maybe for good
> reasons, but again acme is not a general purpose wm.) And see above as
> to why the "points" are pointless.

Well, then propose a detailed way how to handle all problems I
mentioned above in a simple, clear and predictable way.

> > Same with the proposed changes. You just send windows to a
> > specific column or you just destroy/create new columns if you
> > need them. There's not much difference in pressing Alt-n to get
> > a new empty column which is selected already or to Alt-n and
> > taking the selected client to it, or if the current column is
> > set exclusive to create a new column on the fly.
> Little difference? a whole 100% overhead! (it takes twice work), and
> the worst is that then you have to keep track of the newly created
> col, and 1) make sure you get rid of it once you don't need it so it
> doesn't waste space(more work, and delayed work which you will pay for
> later, which is more annoying) and you have to keep track that once

Getting rid of an empty column is somewhat overhead agreed, but
for which price? And pressing Alt-r to get rid of a column is
not that difficult.

> you create the col, the process changes and then you have to first
> select the col and then open the new client(or if it was spawned

No, if you create a col, it is just selected. To run a new
term in a new col you do Alt-n Alt-t. To let an exclusive column
do the job you do Alt-x (set exclusive) Alt-t Alt-Return
(because you have to send the new client back to the exclusive
column). Same interaction points. Your only point is removal of
columns. And this is lesser predictable.

I agree with you, that the tiled layout in 2.5.x or LarsWM is
fairly predictable, because it only consists of two columns and
does not change. but it is rather limited if you got much screen
space or if you want to work in a 2x2 grid or something
similiar. And all those additions you mentioned here are pretty
tricky and only simple and clear at first glance. But not if you
think further about it.

> Yes, and in acme 1) creating/deleting cols suck, 2) when new windows
> show up in the wrong col, you have to re-arrange them by hand, which
> is quite annoying.

I agree that manual creation/removal of cols is not great, but
it sucks less then cluttering all predictability with locking
crap for too few benefit.

> Lets see who is the closed-minded-dogmatic now.

I'm not dogmatic. I (beside of others in IRC) used both concepts
already, that is why I changed my mind.. You can believe me,
that my proposed way is really much simplier, much more
predictable, intuitive, without corner cases and clear then
adding LarsWM stuff to columns.

Regards,

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