Re: [dwm] The answer to Anselm

On Thu, Jul 03, 2008 at 05:10:07AM +0200, QUINTIN Guillaume wrote:
> > Hmm, how would an action argument to arrange() help? What might
> > this argument look like?
>
> The first idea that pops in my head is to have 3 arguments. An int one
> which is an ID defining the action performed on the window :
>
> #define CREATE_WINDOW 1
> #define DELETE_WINDOW 2
> #define TAG_WINDOW 3
> #define UNTAG_WINDOW 4
> and so on ....
>
> The second argument is of type Client*. It represents the window. And
> the third argument is a parameter depending on what action is performed.
> This way my patch can hold in a separate file. Only the resizemouse
> function is altered. We can imagine some lt->resizemouse function, but
> does that correspond to the philosophy of dwm ? Because, like I said it
> would be the first step to support plugins, and, to continue into this
> way, all functions that performs actions on windows like togglefloating,
> toggletag, mousemove, mouseresize, ... should be "lt->"-ed.

Well I don't like this at all. I believe inventing a plugin
interface will make everything more complex and might arise the
need to refactor dwm.

As I told the last time, patches/extensions to dwm are intended
to be lightweight, like an additional layout algorithm working
on a list only, or some handy toggle functions to manipulate
some variables, to make certain working styles simplier.

However, your patch is more heavyweight and if we start to
refactor everything again to allow more complex patches, we will
loose the clarity of dwm. That's why you should patch dwm.c
instead of trying to separate things.

        I believe the best practice to patch dwm.c or not is
        rather simple: if you need to hook somehow into existing
        functionality in two different places, patch dwm.c,
        otherwise, which means you only need 1 hook somewhere in
        your final patch, ask for advice on the mailinglist.
>
> > Well as I told, the wmii column layout is rather static, because
> > it keeps certain clients at a fixed position (in a specific
> > column, at a specific position)
> > [...]
> > And that's it already.
>
> You can move the windows into the column you want, you can change the
> windows' orders in each column and their sizes within the columns. Plus
> the layout is "pertag"-ed. I don't understand why you think that the
> layout is static ? When no window are moved it acts exactly like the

It is more static, because it exposes a more static window
configuration. Windows have fixed positions in columns, and you
need some high-level actions to move windows around. The wmii
layout is equally dynamic to dwm only on a per-column basis.
If you do not touch the height/width of individual clients in a
column in wmii, this particular column behaves as dynamic as the
dwm stack.

To proof that the dwm layout is far more dynamic imagine the
effect of Mod1-0 in a wmii setup. The wmii column layout is not
able to handle arbitrary clients with a satisfying result in
this regard. That's because the semantic of a layout is heavily
coupled with client windows in wmii, whereas in dwm there is no
real coupling between the layout and client windows. The
relevant glue in layout algorithms of dwm are the tag bits of
a client.

Another proof is, changing the layout algorithm altogether. In
dwm it is very simple to switch between different kinds of
layouting algorithms, if they work on a list basis without
having to expect bad results or another additional layer of
auxilliary layout-specific information on a per-client basis.

So going the dwm way, might limit window management a little
bit, if one compares it to wmii or Ion, however, dwm makes it
really easy to integrate simple layout algorithms after all.

And the good thing is, that all dwm-style layouts work well
with the same key bindings, whereas for Ion- or wmii-style
layouts you need to learn a lot more key bindings -- and assumed
a window manager would provide all these layouts alltogether,
you would need to fix the key bindings on a per layout basis.

To be honest, I think that aiming the acme layout in wmii with
resizing individual windows in a column was the wrong decision
(originally I intended to do that, before I gave up the wmii
 development). However, the old hack of column modes seems to be
the far better idea in my own retrospective in wmii, because it
kept the columns at least much more dynamic.

In dwm I reduced the layout concept to a single column in this
regard - and as other patches proof, there are plenty
possibilities to live well with this decision, even if the
concept is more limited.

So I fear you have to live wether with these limits or with a
heavy patch set or maybe your own hg branch, which might it
easier that people can adapt your version of dwm.

> Do you plan to :
> * have a "pertag"-ed wmii layout ?

No

> * resize each window ?

Only in floating layout

> * move window into column ?

No

> * move windows' order within columns ?

There are patches on a per function basis to move clients
up/downwards in the list. But I don't plan to integrate this
into mainstream dwm, because zoom() has the effect of a list
head pop(). So re-arranging the client order is possible, even
if it is more cumbersome -- but usually the master area is
intended to be the main working area.

> Why should the wmii layout be restricted to 3 columns ?
> When I work on a 22" screen I like to have 4 or 5 columns. It has
> already happened.

Well, the wider the screen the more columns you might need. The
limitation to 3 is just the usual setup. You could add a
variable to define the limit, but then the restrict()
functionality would need to take two arguments, like int[2] or
so.

> Why restrict the number of windows in a column ?

That would make the wmii layout dynamic. In dwm the stack is not
intended to have your main focus for a long time, it is just a
temporary area for windows. In wmii columns have equal
attention, thus columns with 20 clients won't be usable anymore,
that's why you wether need column modes or a restriction to the
number of clients.

> What you want to do seems a lot like the tilecols layout contained in
> the nmaster patch to me. And that is not what I wanted.

I know. What I talked about was just an example how I would
implement a wmii-like layout for dwm, with the least
side-effects as possible regarding architectural decisions made
in dwm.

> Well, I agree that the clients linked list is not designed to do what I
> want to do. But I don't think that my patch is heavy patching. There is
> probably a better way to interact with dwm code.

I can't disagree here.

Kind regards,

-- 
 Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361