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
