Messages in this thread | | | Subject | Re: [kbuild-devel] CML2 1.1.3 is available | Date | Tue, 17 Apr 2001 07:11:25 -0400 (EDT) | From | John Cowan <> |
| |
Eric S. Raymond scripsit:
> That way lies featuritis, IMO.
Only if you let it.
> If there were already a library in ths stock Python distribution to digest > .Xdefaults files I might consider this. Perhaps I'll write one. But I'm > not going to bulk up the CML2 code with this marginal feature.
Then support a private mechanism if you must. But leaving colors hard-coded in the application is just as bad as leaving strings hard-coded there, and for the same reasons: it's a point that needs to be adjustable for accessibility. The whole point of CML2 is to make kernel configuration something that Aunt Tillie (or a reasonable facsimile thereof) can do, and we are all Aunt Tillies from time to time. That includes differing standards of readability, quite apart from the differences in monitors that make a Mac user's *red* look more like *orange* to me (and CML2 will be used, perhaps even more often used, off stock x86 hardware).
Without counting, I estimate that 50% of the problem (I won't say "bug" in this context) reports you have had since 1.0.0 have been about colors. The more users you get, the more such complaints there will be. Nail this one to the wall before people start demanding contradictory changes.
If you don't have a full X resources parser, then do a trivial scan of just .Xdefaults and look for a few fixed cases like
CMLConfigure*YColor: 0xrrbbgg CMLConfigure*NColor: 0xrrbbgg
etc. etc. Or provide a private .rc file. Or *something*.
-- John Cowan cowan@ccil.org One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |