In a mail a few days ago, I said > - Some defaults should be the other way around I think. OTOH, I'm > gonna mostly ignore that in this mail, because I'm nearly certain > I'm gonna do that down in the code anyway; expect another mail > about that sometime soon...
So it's soon. I think we should switch the defaults of some settings over the other way from where they are. By defaults, I don't mean what's in the shipped example config; I mean changing in the code where they wind up if the config doesn't say anything. The existing defaults in these cases I think are mostly as they are for reasons that don't apply so much anymore. They even wind up being --unbreak-me sorta things. I'll list out the options by specifying the current config param they'd make the default. In cases where there weren't already ways to express the opposite in the config, I've added them already. First, some that I think are pretty straightforward. These are mostly low-level stuff, where I tend to think it would be very specific and special cases where you'd ever really want the current default behavior. - OpaqueMove and OpaqueResize. The former dates back to twm; the latter came in with ctwm 1.1. The main reason these are non-default is performance; they make the server work a lot harder to keep up. That's why they're so slow and choppy visually, and pretty much make everything else on the system grind to a halt when you use them. Oh, wait. That's all applicable to high-end systems with cutting edge software, like 25 MHz systems running X11R4. - NoBackingStore. This was probably also the way it is for historical performance reasons. Backing store seems to be pretty durn historical, servers paint really freakin' fast, and we've occasionally seen it interact poorly with specific X versions. I don't think it gains us enough to be worth even fairly small extra bug exposure. - NoGrabServer. I'm not entirely sure why this (dates back to twm) is the default it is. Grabbing the server during operations prevents other clients from painting as they get exposed or moved around (maybe performance of that is the reason?). I've also seen X servers go into a busy-loop when positioning windows, etc when grabbed, so they churn up CPU for no reason. - SortIconManager. This also dates back to twm. Why the heck would you ever want the icon manager list things out in the random order it happened to see the windows? That's nutbar. Sorting a dozen strings takes extra CPU, sure, but hey... And then some that might involve a little more discussion and possibly user preference, but I still think are decidedly better the other way around. - StartInMapState. This is probably partially as it is for performance (the map state involves drawing a lot more windows), and partly because the WSM (in button state) existed before the map state was added, so having the default this way preserved the previous behavior. Well, that performance is a non-issue on any hardware not in a retirement home now. That mostly leaves user taste. I have no problem believing some people prefer seeing the labeled buttons to the map, but my gut says the default should be the other way around. - RestartPreviousState. Came in with ctwm 2.1. Probably an option to preserve prior behavior. I think you mostly want ctwm to restart and pick up where it left off, rather than throwing away your occupation and even knowledge of what windows were iconified. And honorable mentions. These are less clear-cut than the previous, but available evidence suggests they're still pretty near universal. - DecorateTransients. Goes back to twm. Every twmrc I've ever seen, including the twm and ctwm shipped defaults, pretty much every one I can find with Google, and even default configs in FVWM (different way of config'ing, but same semantic), has this set. - RandomPlacement. I'll bet there are old twm-heads who want to manually place every window that comes up and not be able to do anything else until they do. But I'd give good odds there are a zarking lot more on the other side. And like the above, it exists in pretty much every config file I can find out in the world. Comments? Agreements? Arguments? Torches and pitchforks? Cake? -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
