On Fri, 3 Nov 2006 11:48:55 +0100 "Anselm R. Garbe" <[EMAIL PROTECTED]> 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.
pgpuCdXwsh6qz.pgp
Description: PGP signature
