Re: [wmii] Preparations for 3.5

On Thu, 2 Nov 2006 22:50:52 +0100 Denis Grelich wrote:
> On Thu, 2 Nov 2006 19:32:55 +0100 thomas <thomas.bsd_AT_gmail.com> wrote:
> > 2006/10/31, Denis Grelich <denisg_AT_suckless.org>:
> > > If you want a C wmiirc, you could as well have all of the config
> > > in-source, or have a config file in some special format that is read
> > > and parsed by wmiiwm. These could be options for wmii-4 though. For
> > > 3.5 I definitely don't want to change the well-tested current
> > > concept. Another approach would need much design and many
> > > iterations.
> >
> > I know lots of people here speak C as a second language and despise sh
> > and the coreutils ("Linux is crap, GNU folks are morons", etc.) but I
> > may not be the only one who prefers writing a shell script as hacking
> > a c file. One of the thing i do like about wmii is the ability to
> > customize the wmiirc and status scripts. If I want wmiirc to do some
> > stuff on startup or update the statusbar with a niceness of 19 or if I
> > want to write shell functions() for the shortcuts, I can do that
> > easily. If I want the statusbar to show me incoming email, no problem,
> > etc.
> >
> > 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.
This performance increase is what I'm thinking of. I'm working on
rather old machines most of the time, where many of the nowadays
no longer considered optimizations lead to noticeable performance
increases or decreased delays. And also I consider waste of CPU power
not a good programming practice even if one could say "you won't
notice". Add them all up and then you will notice...

> > I'm not an expert and maybe a part of wmiirc should be rewritten in C.
> > So far, the decisions made about the design of wmii look really sound.
> > But please, don't break the ability to customize wmii just to show off
> > your proficiency in C or something like that.
> This is not intended in any case. It's all about pragmatic solutions.
Yes, I think keeping a standard wmiirc in sh is good. Also
a C-solution should provide useful standard functionality and
simple extensibility regarding keyboard shortcuts and such at
runtime. It could provide enough to replace the sh-script as default,
while the option of scripting in sh/perl/ruby/python is still there...
(for those fancy features).

And regarding the scripting interface, Anselm's idea of replacing
the 9P filesystem with a simple command input via stdin is worth
thinking of for wmii-4. It makes one wonder a bit, why the 9P
interface has been chosen instead in the beginning, but I appreciate
his courage to admit that this may have introduced too much overhead.
On the other hand, the question arises how to provide all the
information about tags and clients via the stdin/out interface?
Sending commands is easy, but retrieving non-event information...?

Regards,
Stefan

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer