Re: [wmii] snap: 20060309

From: Uriel <>
Date: Thu, 9 Mar 2006 19:58:54 +0100

You are a total idiot and have no sense of style, proportion,
perspective and sanity.

You are totally blinded by totally meaningless mumbling about LOC of
code that doesn't even exist (and which functionality is not even
defined yet!). But hey, seeing your track record I'm sadly not
surprised that you can't even have the most
minimal amounts of perspective about things. Like if LOC mattered more
than anything else, well, then don't frking write any software and use
pen and paper! that surely beats everything else at low number of
lines of code.

The rules file should be inside wmii, for the same reason the plumber
rules are inside the plumber: it is simpler and cleaner. They specify
the default set of tags, and the one that initializes the tags is the
wm, so the information about how to initialize tags should be stored
and maintained by the wm because it is the one that knows best the
context of the creation of the window.

Of course once more you are blinded by your total incapability to
think in more than one single straight line at a time, and assume that
just because the wm sets the default tags like that, it should not
allow external programs to set the
tags, which obviously is a totally senseless conclusion.

If you don't learn to step back, and to see how the small pieces fit
into the big picture, and how all the different design factors
interact; and instead keep dogmatically following totally arbitrary
and senseless metrics to measure how things should be done, we are
hopeless. Programming is an art, not an exact science, and it requires
a sense of aesthetics, style and perspective; and like ken said, one
has to see how the small pieces fit into the big structures.

Now go ahead and ignore everything I say and build your extremely
complex system to push tag initialization logic into external
programs, that then call xprop, parse xprop output, then write to the
tag file, and then say they are done figuring out what tags should be
selected, etc. Great idea, push all the tedious work to the user, to
save a handful of hypothetical lines of code. Blah, if you only could
read The Practice of Programming, which has a whole chapter dedicated
to the power of small specialized languages.

After taking a look at xprop, I am in awe as to what sort of perverted
mind conceived such abomination, and how anyone could ever use a
system as retarded as X; but still, I can't see how we could not just
pick a handful of attributes (most of which we probably are needed by
wmii internally anyway) and export those as strings, I certainly see
no sense in allowing to set any of them, but if we are going to fetch
them anyway, why not provide a sane interface to them rather than the
xprop insanity.

On 3/9/06, Anselm R. Garbe <> wrote:
> On Thu, Mar 09, 2006 at 05:27:12PM +0100, Uriel wrote:
> > On 3/9/06, Anselm R. Garbe <> wrote:
> > > On Thu, Mar 09, 2006 at 04:39:48PM +0100, Uriel wrote:
> > > > This "calss" system seems way too complicated (I don't think I even
> > > > understand it)
> > > >
> > > > All that is needed is a single file that contains one rule per line:
> > > > /pattern/ -> tag list
> > > >
> > > > Inside /pattern/ you could have either regexps or shell-style globing. Only
> > > > think that should be taken care is that it should be possible to match other
> > > > attributes than "class:instance".
> > >
> > > I like your idea, except that I hope you don't mean to have such
> > > file in wmii's virtual filesystem,
> > Of course I do mean inside the wmifs, just like /mnt/plumb/rules,
> > xprop output totally sucks, what wmii should provide is a way to setup
> > a convenient set of rules.
> I really hope you're not kidding, because that sounds totally
> insane. Sure, xprops output sucks, but I don't care. Also wmii
> won't be able to provide you equivalent output like xprops,
> because xprops prints all(!) atom properties associated with a
> window, you don't want to know how much crap you have todo, to
> get something similiar (beside reinventing square wheels). (I
> expect not under 2kSLOC at least for dumping/querying the
> stuff).
> Then implementing yet another regex-matching/globbing rule
> engine similiar to awk, to just match some properties to write
> some tags to windows inside wmii, what do you think how many
> SLOC will that be? I expect at least 0.5-1kSLOC for very basic
> stuff. Then you need an fs-interface for it which will need also
> approx. 50 SLOC additional lines. Thus all in all we would be
> around 10kSLOC I presume, for stuff which can be much more
> simplier I already showed. We could even get rid of /def/tag
> stuff, because wmiirc could decide what the fallback tag should
> be.
I never have seen any need for /def/tag, and still think it should not exist.

Received on Thu Mar 09 2006 - 19:58:58 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:00:54 UTC