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 <[EMAIL PROTECTED]> wrote: > On Thu, Mar 09, 2006 at 05:27:12PM +0100, Uriel wrote: > > On 3/9/06, Anselm R. Garbe <[EMAIL PROTECTED]> 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. uriel
_______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
