On Tuesday 12 September 2006 03:05, Anselm R. Garbe wrote:
> Hehe, I won't complain about any fork. However, you don't need
> to. If you know anyone who wants seriously maintain wmii and
Oh, heck... I wouldn't. I don't have enough time to work on my own open
source projects. And I'm pretty happy with WMII the way it is right
now, anyway.
> > having a back-seat driver. That's when it'll fork.
>
> Maybe you misinterpreted my statement. I'm not intending being
I don't think so; I thought all of your suggestions for future
development of WMII were good, and I took them as such. I was mostly
enjoying the diversion that Doug started by suggesting that the person
making design decisions might best be the person who's doing the work.
It was all hypothetical, anyway.
> the conclusion that tagbars and the 9P interface are nice ideas
> but don't really provide much benefit in a window manager (they
Again, I don't *see* 9P. If implementing wmiir is easier because of 9P,
then I think 9P has value, but what I care about -- as a user -- is the
functionality of wmiir.
wmiir fills a role that is very similar to KDE's dcop, albeit focused
entirely on the window manager. It is quite powerful, and very easy to
use.
> 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 all sound entirely reasonable.
> 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...
Well... it needs *some* interface for this, as far as I'm concerned.
I'm not satisfied with having to recompile, reinstall, and restart the
window manager just to change my configuration. I *love* the fact that
I can implement the hotkey event loop entirely in a language of my own
choosing.
> > 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
Well... I don't know about the 80's, but I was using Solaris in the
early 90's, and I'm certain that I never changed the configuration of
any program by editing a header and recompiling. tar, ls, ps, CDE...
they were all configured by either command line arguments or config
files.
For that matter, for as long as I can remember, there's been an /etc in
UNIX, full of non-compile-time config files. passwd, groups,
resolv.conf, services, hosts, etc., etc., etc.
> source has been patched. Why does anyone want to spent man
> months to write wmiirc-replacements to lookup a specific client
Man months? I rewrote my wmiirc and status in Ruby within an hour or
two, within hours of first compiling and running wmii. I'm still
tweaking wmmirc, adding key bindings as I discover what I miss most
from KDE.
Again, I have nothing against DWM, and I'm sure that it fills a niche.
I prefer WMII, but it doesn't matter, because they're different
projects. There seems to be a lot of discussion about the two, as if
they're competing. Which I didn't think they were.
> 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
Yes, I have. I don't think it would be *easier* to configure mutt by
customizing the sources, but it certainly wouldn't be harder.
Now, sendmail... THAT would be easier to configure by editing the
sources. Or, you could run something like postfix, which doesn't have
obscene configuration files.
However, wmii is much less complex. wmiirc is *easy* to understand.
Even if it weren't, wmiir _is_, and once you have wmiir, you can write
wmiirc in any language you like, and that's _certainly_ easier than
editing the sources (unless you prefer C).
There's an added benefit to not editing the sources: safety. C is easy
to write poorly -- if you don't believe me, ask me to write some C code
for you -- and if the user breaks wmii, then their window manager is
shot. If I screw up wmiir, then -- so what? I lose access to my
hotkeys until I fix it. Which doesn't require restarting X.
> how much code has been implemented to support all those funky
> mutt options... not to mention how messy the vim code might look
There's a project called libelektra, which provides a simple (in size,
dependencies, and complexity -- much like wmii and dwm, in fact)
library for configuration. You link to the library and use library
calls like getKey, setKey, and elektra handles storing and reading all
of these values from the filesystem. The goal was to allow programs
access to configuration code without having to re-implement it.
http://www.libelektra.org/Main_Page
If the only reason for limiting configuration changes to rewriting code
is to remove configuration parsing code, then libelektra is (IMHO) a
better option.
> What's the difference between learning C header syntax, shell
> script or some propietary config file syntax? Besides this, the
There isn't. That's partially my point. With recompiling, you have to
learn the C header syntax, you have to recompile, you have to
reinstall, and you have to restart. With a config file, you have to
learn the syntax, and you have to reload the config. 50% of the
(quantified) effort.
> config.h approach has the advantage that you know syntax error
> right before using the configuration ;)
Hah! That's a laugh. Since when does "it compiles" equate to "it will
run (correctly)"? We're talking about C, after all... not Haskell.
> > 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.
Sorry, I wasn't clear. I was saying that WMII is very
resource-friendly. Therefore, it is an attractive (good) option for
computers with very few resources. Which means that it is not unlikely
that somebody will be running WMII on an old computer, in which case,
it *might* be laborious to recompile the window manager just to change
a configuration option.
> 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.
Hey, that's a great idea. Thanks.
I, however, am not running on a resource-challenged computer; the
once-per second fork()s of `status` are not noticeable, and there's
only one fork() in wmiirc for the main event loop.
> 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 ;)
Then you're wrong! There wasn't anything to learn. It was obvious from
wmiirc how wmiir worked, and i already know how to write Ruby.
Granted, it did take a couple of hours to actually rewrite everything,
but now, adding key bindings really does take but a few seconds. It
would take *just* as long to change the headers for dwm, AND I'd have
to recompile and reinstall it. There is simply no way that it is
faster to reconfigure DWM than it is to reconfigure WMII, even without
rewriting wmiirc. However, it may be more *comfortable* for you to
edit a .h file than a .sh file, which is something entirely different.
That's a matter of taste, and I can understand that.
--- SER
Confidentiality Notice
This e-mail (including any attachments) is intended only for the recipients
named above. It may contain confidential or privileged information and should
not be read, copied or otherwise used by any other person. If you are not a
named recipient, please notify the sender of that fact and delete the e-mail
from your system.
_______________________________________________
[email protected] mailing list
http://wmii.de/cgi-bin/mailman/listinfo/wmii
