Re: [wmii] WMII & screen rotation

From: Anselm R. Garbe <>
Date: Tue, 12 Sep 2006 09:05:42 +0200

On Mon, Sep 11, 2006 at 03:25:26PM -0400, Sean Russell wrote:
> On Monday 11 September 2006 07:46, Anselm R. Garbe wrote:
> > On Mon, Sep 11, 2006 at 07:33:49AM -0400, Doug Bell wrote:
> > > Anselm R. Garbe wrote:
> ...
> > > > need another maintainer for wmii. I won't do the job again,
> > >
> > > So you refuse to maintain wmii and there is no visible replacement
> > > maintainer, but you are still directing it's development? Do you
> > > expect this to work?
> > As long as wmii is hosted on my server it has to work ;)
> Fork!!!

Hehe, I won't complain about any fork. However, you don't need
to. If you know anyone who wants seriously maintain wmii and
who has enough knowledge and interest to do so, let me know.
The infrastructure is there already. But let's have some more
patience for Kris. He did a really good job with the fs.c
reimplementation. And also in other parts.

> for a mailing list. At the moment, I don't opine that anything that
> Anselm is suggesting for WMII is bad; it all sounds good. But I can
> certainly believe that if somebody decides to take up the mantle (and
> effort!) of primary developer, they may object to having a back-seat
> driver. That's when it'll fork.

Maybe you misinterpreted my statement. I'm not intending being
an back-seat driver or making decisions on wmii development.
Most stuff in wmii has been developed by me, however I came to
the conclusion that tagbars and the 9P interface are nice ideas
but don't really provide much benefit in a window manager (they
have their place for other tasks, like done in acme). But having
tagbars to close a window (similiar to acme) is much less
efficient in use to me than remembering a shortcut to do so. But
this might be personal taste, so I don't intend to make that a
general statement.

During the fact that I'm one of maybe 5 persons in the world who
know any detail in wmii, I got some ideas to make the job of a
future-maintainer of wmii easier. Those are basically separating
stuff which don't needs to be included in wmii like libixp,
wmiimenu and wmiir. Despite of this, the idea to separate libixp
into two libs (libnet and libixp) is not by me, it is from Kris,
but I agree with him and I support this decision. I'm also
willing to contribute work to achieve this. The decision to
abandon the efforts for liblitz are mainly grown on my
experience, because I originally planned to continue liblitz to
get a tagbar widget, but I realized that all abstractions
necessary for such a widget are far more complex, than making
the tagbars a simple builtin feature in wmii. There are many
reasons, but the most important one is, that I don't want to
duplicate the event handling to implement tagbars.

> Replacing it with ... what? At the moment, wmiir is magic to me. I
> know it uses 9P in there, somewhere, but as far as I'm concerned, it
> could be using any old socket protocol to communicate with wmii. As
> long as the end result includes something like wmiir, so that I can
> continue to script wmii with Ruby, then I'm happy.

Replacing 9P has never been my intention. It is the best
protocol we can get, esp. because it has been designed by UNIX
wizards. I only ask if a window manager really _needs_ an 9P
interface which is mainly used to make the window manager appear
with different colors and to grab for different shortcuts...

> > > I've written configuration file parsers before. It isn't that
> > > tough. Please re-consider this decision.
> Is the concern that wmii will be abandoned because Anselm working on
> dwm?

I hope not.

> > This is UNIX, and it has tradition to customize software in its
> > source code. dwm is dedicated to point out this tradition.
> Hmm. I'd debate that. I know very few Unix programs that don't take
> arguments (which are a form of configuration), and many will take their
> arguments in the form of a config file.

I don't refer to the way recent linux distributions are managed,
I refer to how UNIX worked in the 70s and 80s. Everything has
been source-based and if a tool should behave differently, its
source has been patched. Why does anyone want to spent man
months to write wmiirc-replacements to lookup a specific client
instead of implementing a 10 line C function? Actually you are
right, dwm is not for everyone, it is mainly only for me and
might be of use for other(C developer)s. Source based
configuration is one reason for having the source in my eyes. I
don't need the source if I only want to customize software
through editing arbitrary config files. But this is Open Source,
isn't it?

> > Is it more time-consuming to edit a config.h file and
> > recompile the whole source code in 3s than learning yet another
> > config file syntax and editing a config file? I think the 3s
> Yup! Because it takes me three seconds to learn the config file syntax,
> and I only do that once. Editing the config.h file and recompiling is
> going to consume that time over, and over, and over...

I doubt it is more time consuming. Have you ever worked out a
nice .muttrc? I think if mutt would be a simple piece of
software like dwm, it would be more easy going to customize its
source code for my needs, then reading a huge man page which
describes any of all 10000 options. I also don't want to know
how much code has been implemented to support all those funky
mutt options... not to mention how messy the vim code might look
already (I heared of old UNIX users who still laugh if they
learn a new 'feature' or 'option' in vi(m) after 20 years of
use). At least it was easier to patch acme for a specific
behavior than searching for some obfuscated option for .vimrc.

> Also, you're assuming that someone already knows the C header syntax,

What's the difference between learning C header syntax, shell
script or some propietary config file syntax? Besides this, the
config.h approach has the advantage that you know syntax error
right before using the configuration ;)

> compiler. It isn't absurd to assume that somebody is using old
> hardware to run WMII, especially considering WMII's attractive runtime
> resource requirements.

If something is really resource-attractive in wmii, let me know.
Despite of the wmiir redirection I can't believe that (that's
why I'd recommend native 9P clients like that ruby-ixp interface
instead on such systems). Sadly fork()'s are quite expensive in
UNIX environments.

> My point is that there is at least one user of WMII who feels that he's
> justified in changing his configuration periodically, and I doubt that
> I'm the only one.

There is nothing wrong with changing the configuration. But I
doubt you spent more time in customizing dwm than learning how
to write a wmiirc replacement ;)


 Anselm R. Garbe  ><><  ><><  GPG key: 0D73F361
Received on Tue Sep 12 2006 - 09:05:42 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:13:40 UTC