Re: [dwm] snapping bugs with multiple screens

From: Matthias-Christian Ott <>
Date: Mon, 05 May 2008 18:05:46 +0200

hiro <> wrote:

> > There is this stupid idea called democracy (just in case you heard of
> > it) and I tried to establish just a tiny fraction of it here in the dwm
> > development process. Shame on me!
> At the beginning dwm was Anselm's baby, and he said it shall only fit
> his needs. He made this very clear and I fully respected this. Dwm
> never really fit my own needs, but it was still an interesting
> approach. And, like you said, Matthias, there is always the
> possibility of an own branch.

Well, dwm doesn't really fit my needs too (because I have a monitor
that's obviously too small), but it fits better than everything else I

> > For me it the dwm development process seems to be kind of fair, Anselm
> > mainly tries improve dwm based on the needs (and patches) of the people
> > here on the mailing list unless they don't interfere with the
> > development philosophy.
> > But due to the development philosophy of dwm you can't make everyone
> > happy and integrate every feature.
> Yes, what is the development philosophy? If i remember correctly it
> was all about being small, simple and elitist.

I mean with development philosophy mainly Anselm development philosophy,
because as you mentioned Anselm is the primary maintainer.

> But there are always compromises. So, there has to be a decision about
> what features to support.

Yes, of course. And this has to be discussed (with a certain "framework"
of course - you can't come along and expect someone to integrate cairo
or so). And this is why we have to make clear what exactly sucks less.
I mean the term itself suggest that we're not developing software on a
solid basis and have to make the best out of it.

> Recently there were all these changes with monocle and xinerama; And
> of course things get more difficult this way, so i would have
> respected i.e. not including such features at all.

Well, this depends on your viewpoint, more precisely what you consider
superfluous and what not. For some people xinerama and monocle may have
been a great improvement for a relatively small amount of source code.

> But at some point the decision was made about Xinerama support, and
> since then development seemed going forwards and backwards, aimlessly
> and probably startled from all these bad X dependencies.

Well, X11 is a monster and really sucks. All we do here is to tame it so
it doesn't eat us. We have to make the best out of it.
Certainly everyone agrees that X11 should be replaced, but this takes
time and needs people. And because we have none of these resources, we
have to stick to it.
I mean do you think GNU/Linux is the holy grail of operating systems?

The aim of dwm is to be simple, small and clear, but sometimes you have
to make trade-offs. And I think in this case multiple monitor support
was a relatively good trade-off.

> Dwm shouldn't focus so much on *how much* X features suck, but rather
> on doing one thing (whatever this is), and then of course, doing it
> good.

Exactly this is the problem: Everyone may have a different opinion of
the one thing and the intersection is of this opinions (supervised by
the maintainer) is the software.

I think that software and software development has to be planed by smart
people and realised by good programmers. But sadly this is not the case
in reality, so we have to use dwm and talk about X extensions.

My approach for this problem would be:
  1. Write the patch
  2. Count the lines of source code
  3. Compare the result to benefits of the patch and design principles
  4. Integrate it or drop it

Obviously you can't make everything a pipe line filter and can't
abstract everything very simply. And I think this (maybe due to the
design of X11) one of this cases where there has to be a monolithic
implementation. Due to this there has to some kind of comparison and
And in the end Anselm decides what goes in to the main repository.

Received on Mon May 05 2008 - 18:06:12 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:37:07 UTC