Re: [wmii] Preparations for 3.5

On Fri, 3 Nov 2006 11:48:55 +0100
"Anselm R. Garbe" <arg_AT_suckless.org> wrote:

> On Thu, Nov 02, 2006 at 10:50:52PM +0100, Denis Grelich wrote:
> > > What would be the advantage of a C replacement? A cleaner code?
> > > Frankly I don't mind if wmiirc is not a masterpiece, so long as it
> > > works. A 0.017 second faster wmiirc? Idem, I really don't care
> > > about such speed optimizations, saving 1K RAM seems so pointless
> > > to me... As for the "more powerful scripting language", do I
> > > seriously need Python/Ruby/whatever to make the statusbar show me
> > > the volume or the currently played song?
> >
> > Just as a sidenote: the performance increase would be perceptible. I
> > can't find the link atm, but someone did benchmark this and found
> > pretty high differences for different implementations, two-digit
> > magnitudes.
>
> What I learned from dwm development, and which encouraged me to
> develop dwm is, that it does not provides a 9P interface,
> because I think a 9P interface is too exeggerated for the
> purpose of a window manager. To keep the same flexibility but
> with a much simplier approach, you could think about defining a
> command interface which is read from stdin and special results
> written to stdout. This way, one could wrap wmii in a script,
> whereas /event is simply stdout, and all commands are written to
> stdin. This way, you could drop all the complexity and gain a
> rather simple interface to interact and extend the window
> manager. In dwm all input is displayed as status text, and there
> is no plan to extend this. But if you really want to simplify,
> I'd really consider dropping the 9P interface.
>
> There are reasons why a 9P interface makes sense for different
> tasks than managing windows, but in a window manager I really
> doubt its usefulness. Especially because much stuff in current
> hg tip has been simplified by Kris to commands which are written
> to specifc ctl files (eg. for setting colors and such stuff).
>
> Writing to stdin and reading from stdout using fifos does not
> need many additional processes, especially no atomic ixpc
> (==wmiir in the past), you can simply use the redirections of
> the shell.
>
> My idea is rather radical how I'd control wmii-future from a
> script: just drop the wmiirc script and put that stuff into the
> wmii script which should be user-supplied, this produces lesser
> clunk and is still easy.

I don't like this idea. The 9P interface is very easy to use and keeps
interaction pretty straightforward. I doubt the difference would be
gigantic (there definitely would be one, though), since you still have
all the brakes of the shell -- standalone processes for every string
manipulation and maybe calculation. It could be even worse: if you have
only one channel to communicate, you have to do much more serious
parsing. What you would lose on the other hand is quite some
flexibility. I think paying the price of 9P is alright. It might be
something different on old and slow machines, but I don't want to think
of wmii as a »poor man's« window manager. Anyway, these are thoughts
for wmii-4 already.