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

On 3/3/06, Anselm R. Garbe <garbeam_AT_wmii.de> wrote:
> On Fri, Mar 03, 2006 at 03:31:27AM +0100, Uriel wrote:
> > What the hell are you people thinking? This removes the whole dynamic
> > concept of cols, and makes it almost impossible to get a larswm-like behaviour.
>
> 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.

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

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

>
> > On 3/2/06, Sander van Dijk <a.h.vandijk_AT_gmail.com> wrote:
> > > - column capacity has to go, because it adds more to complexity than
> > > to usability; if users want to limit the amount of clients in a
> > > column, they'll have to do so manually.
> > Who the hell came up with the idea of "capacity"?!?! the idea was
> > _exclusive flag_
> > which is simpler, clean and easy to understand.
>
> 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.

> And this capacity stuff has several implications I noticed and
> which suck in my eyes:
>
> 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.

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

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

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

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

> 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
lame and pointless of all, exclusive and max are totally independent,
exclusive just means the wm enforces having a single client on this
col all the time, you could as well have a single client on a col even
if the exclusive bit was not set, and behaviour would be _identical_

> > Note: probably "exclusive" flag would actually mean 'push all new
> > clients to the right' so it can be easily set on cols that have
> > already more than one client, I certainly can't see why there should
> > be anything difficult about its implementation.
>
> See above.
>
> > > - more "CN " events: for instance when removing the last client from a
> > > page, when selecting an empty page, maybe others?
> > I can see why anything of this might be needed at all, actually, if
> > all pages are created 'on the fly' by using the tag-ws I described
> > before or some other way, this becomes completely unnecessary.
>
> 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.

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

> > This makes the whole system much more dynamic as one can create and
> > delete windows and one doesn't have to worry about keeping track of
> > existing cols and of reclaiming the space of empty cols, and one
> > doesn't waste space with the title for the col.
>
> 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
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
automatically, then you have to worry to move the client to the right
col)

>In normal usage
> scenario you will end up very fast with two or three columns
> without thinking what impact the kill or sendto of a specific
> client has. It is like acme, so you can imagine.
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.

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

uriel
Received on Fri Mar 03 2006 - 12:30:52 UTC