On Mon, 12 Apr 2010 at 0:19:32 +0200, Tamas TEVESZ wrote: > > looking into how to integrate the shiny new wmgenmenu into > wmaker.inst, i came to the conclusion that doing what debian does > is a better way. > > in short, in debian, "wmaker" is a shell script similar in purpose to > wmaker.inst, as in it does the user-level setup *if needed*, then it > just execs the real wmaker. > > i think we should adopt this. it more or less completely replaces > wmaker.inst, except wmaker.inst will modify your > .xinitrc/.Xsession/something else too.
I won't disagree with your judgement on this matter, but on a first look of debian/wmaker.sh (that's what you mean, right?) I didn't quite became a fan of what I saw. It's a 70+ line shell script which ultimately for 99.99% of the time will simply execute the last line. I much rather prefer doing the install stuff once at wmaker.inst, and then the other 99.99% of the time simply do a "run the wmaker binary as fast as you can" and saving every 0.1 sec you can get. I exaggerate a bit, but I don't like the overhead of loading unnecessary stuff at startup at a theoretical level (ie even if it means a 0.01 sec delay on a fast computer). [ And now I have an Intel SSD and those kind of things become less-then-milliseconds issues, but until recently I had the worst 4200rpm drive ever made in the history of the hardware industry, and loading even a few libraries would mean a stupid delay. Just yesterday I spent some time to make my wmaker not load the libtiff and libgif and thought about stripping even more stuff, but strictly speaking I don't need to do these kind of things anymore and do it just by force of habit and for the 4200rpm trauma :-)] So if you can find a solution where we don't use a shell script to check things at every load, I would be theoretically happier. But if you don't I can live with sub millisecs delays, I guess... :-) -- To unsubscribe, send mail to [email protected].
