Re: [wmii] Preparations for 3.5

On Fri, Nov 03, 2006 at 11:48:55AM +0100, Anselm R. Garbe 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.
>
> Just some thoughts...

To make my proposal more precise, I think of something like
this:

#!/bin/sh
# wmii start/control script

mkfifo $HOME/.wmii/in
mkfifo $HOME/.wmii/out

# setup
cat <<EOF > $HOME/.wmii/in
ungrab
grab $MODKEY-a
grab $MODKEY-b
grab $MODKEY-c
titlecolor '#ff00ff'
EOF
while true
do
        cat $HOME/.wmii/in
done | wmiiwm |
while read event
do
        case "$event" in
        $MODKEY-a)
                # do action on $MODKEY-a
                echo attach > $HOME/.wmii/in
                ;;
        esac
        #...
done

In my opinion this provides rather similiar flexbility like a 9P
interface, but with lesser overhead.

Regards,

-- 
 Anselm R. Garbe >< http://suckless.org/~arg/ >< GPG key: 0D73F361