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/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:21 EST