CML2 1.1.3 is available
CML2 NEWS
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.1.3:
* Freeze color changed from cyan to blue.
* Tom Rini's network-configuration patches.
* Better detection of set variables to be colored green.
* Minor resize and scrolling fixes in menuconfig.
* Fixed a rather nasty bug involving side-effect computation that showed up if you set, unset, and reset a symbol in a choices menu.
* In non-choice menus, select bar is now advanced after [ymn].
Point release -- bug fixes and UI cleanups.
Signature · 7 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The only purpose for which power can be rightfully exercised over any member of a civilized community, against his will, is to prevent harm to others. His own good, either physical or moral, is not a sufficient warrant -- John Stuart Mill, "On Liberty", 1859
Quoted 6 lines · Eric S. Raymond
CML2 NEWS
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.1.3:
* Freeze color changed from cyan to blue.
I suggest you stop dinking the colors. There will always be some colors, for some screens, for some eyes, that are illegible, culturally unacceptable, or otherwise bogus.
Instead, read the colors from the .Xdefaults system.
Signature · 4 lines
There is / one art || John Cowan <[email protected]> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Quoted 6 lines · John Cowan
Quoted 2 lines · Eric S. Raymond
Release 1.1.3:
* Freeze color changed from cyan to blue.Instead, read the colors from the .Xdefaults system.
Yes, truly this should be done. Sensible defaults should be used (and I think we may be at that point) and then use .Xdefaults (.Xresources or whatever) to allow site overrides. And I really do think .Xdefaults and not .xconfigrc or something. I've already got enough .files and I like the syntax of .Xdefaults.
James Rich
[email protected]
james rich <[email protected]>:
Quoted 7 lines
Quoted 1 line
Instead, read the colors from the .Xdefaults system.
Yes, truly this should be done. Sensible defaults should be used (and I think we may be at that point) and then use .Xdefaults (.Xresources or whatever) to allow site overrides. And I really do think .Xdefaults and not .xconfigrc or something. I've already got enough .files and I like the syntax of .Xdefaults.
That way lies featuritis, IMO.
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.
Signature · 11 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The conclusion is thus inescapable that the history, concept, and
wording of the second amendment to the Constitution of the United
States, as well as its interpretation by every major commentator and
court in the first half-century after its ratification, indicates
that what is protected is an individual right of a private citizen
to own and carry firearms in a peaceful manner.
-- Report of the Subcommittee On The Constitution of the Committee On
The Judiciary, United States Senate, 97th Congress, second session
(February, 1982), SuDoc# Y4.J 89/2: Ar 5/5Eric S. Raymond scripsit:
Quoted 1 line
That way lies featuritis, IMO.
Only if you let it.
Quoted 3 lines
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*.
Signature · 3 lines
John Cowan [email protected] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
Quoted 10 lines · Eric S. Raymond
Date: Mon, 16 Apr 2001 20:55:56 -0400
From: Eric S. Raymond <[email protected]>
To: james rich <[email protected]>
Cc: [email protected], [email protected]
Content-Type: text/plain; charset=us-ascii
Subject: Re: [kbuild-devel] CML2 1.1.3 is availablejames rich <[email protected]>:
Quoted 2 lines
Quoted 1 line
Instead, read the colors from the .Xdefaults system.
Quoted 7 lines
Quoted 5 lines
Yes, truly this should be done. Sensible defaults should be used (and I think we may be at that point) and then use .Xdefaults (.Xresources or whatever) to allow site overrides. And I really do think .Xdefaults and not .xconfigrc or something. I've already got enough .files and I like the syntax of .Xdefaults.
That way lies featuritis, IMO.
Agreed.
Quoted 3 lines
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.
This presumes one is using X. On a non-X system, .Xdefaults should mean nothing. If anything I think cml2 is no different from anything else. Some sane colors should be chosen to default to, preferably not too far off from CML1menuconfig, and leave it more or less like that. If it _must_ be configureable, put it in a ~/.cmlrc
Then do the equiv of:
${CMLRC:=~/.cmlrc}
If someone doesn't like the extra dotfile in ~, they can set
CMLRC=~/.etc/.cmlrc
or somesuch from ~/.bashrc and friends. Anything more would be indeed featureitis IMHO, or abusing a defined file format (Xdefaults).
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
John Cowan <[email protected]>:
Quoted 19 lines
Quoted 3 lines
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.
Quoted 7 lines
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: 0xrrbbggetc. etc. Or provide a private .rc file. Or *something*.
Unfortunately, life is not so simple.
X speaks RRBBGG -- or does it? Suppose the user isn't running in 24-bit true-color mode; do I do my own dithering or quantization? The terminal emulators only know about the 16 EGA colors. So, should I support separate resource formats for X and menuconfig cases? But wait! The Linux console does RRBBGG.
Other possibility: support only the 16 EGA colors by name. But if I do that, some of the X colors are just *wrong* on standard gray background (cyan is a good example).
There's no way to get this right. So I choose to get it wrong in a simple way rather than a complex, costly way.
Signature · 5 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "Extremism in the defense of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess)
CMLConfigurator skins (was: CML2 1.1.3 is available)
In reply to Eric S. RaymondQuoted 1 line · Eric S. Raymond
Other possibility: support only the 16 EGA colors by name.
Excellent idea!
Quoted 3 lines
But if I do that,
some of the X colors are just *wrong* on standard gray background (cyan is a good example).
So let the user set the background color too. I find gray backgrounds a mortal pain (the "standard" 75% gray of browsers, e.g., is a bad compromise between pictures, which want 50% gray, and text, which wants 100% gray = white).
When I write HTML, my only concession to non-Strictness is a "bgcolor='white'" attribute in every <body> start-tag.
Quoted 1 line
There's no way to get this right.
There's no way to get it Good and Right for all, without more work than you are willing to put in, following the hacker *mabla*-tradition of basically ignoring UI/HF issues.
But it is still possible to make it Bad and Right, using such a hack as described above. What you have now is Good and Right for some and Bad and Wrong for others, and the number of "others" can only grow --- no matter how much you dink the colors in Brownian motion, responding to random electromagnetic forces from randoms.
Quoted 2 lines
So I choose to get it wrong in a simple
way rather than a complex, costly way.
Don't say you weren't warned, nag, nag, nag, ...
My strategy here is to make sufficient fuss that you are motivated to get off your duff to shut me up. :-) Better me than some irate newbie who decides that configuring kernels "can make you blind, man".
And whilst you are implementing this, make sure a range of font sizes is allowed in the X version. My middle-aged eyes are more and more happy with the "huge" setting in the xterm control-rightbutton menu, especially on SuperVGA screen sizes.
Signature · 4 lines
There is / one art || John Cowan <[email protected]> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
[John Cowan]
Quoted 4 lines
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,
Come on, that's absolutely a red herring. There are valid reasons to want to configure your color schemes, but Aunt Tillie is not one of them. Do you seriously believe the novice user will ever futz with a ~/.kernelconfigrc file? I don't. Only the (relatively) advanced user will bother to figure out stuff like that.
If you want your aunt to be able to set her own colors, you basically have to provide an 'Edit / Preferences...' drop-down or equivalent, and I think we all know we don't want to go *there*....
Quoted 3 lines
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.
Which basically means Eric and the others have long since shaken out the serious bugs. -- Except for the famous 20-second parse, which of course accounts for the *other* 50% of recent CML2 traffic.
Peter
[esr]
Quoted 4 lines
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.
Wait ... I thought you were just using Python bindings to Tk. Are you telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources?
Peter
Peter Samuelson <[email protected]>:
Quoted 4 lines
Wait ... I thought you were just using Python bindings to Tk. Are you telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources?
If it does, it's not in any of the documentation I've ever seen.
Signature · 7 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861
Quoted 7 lines · Eric S. Raymond
Peter Samuelson <[email protected]>:
Quoted 4 lines
Wait ... I thought you were just using Python bindings to Tk. Are you telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources?
If it does, it's not in any of the documentation I've ever seen.
In Tcl/Tk, it's the "option" command.
Andrew
Quoted 3 lines
Quoted 3 lines
telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources?
Of course it does; in an idiosyncratic way (not directly using X resources) but it does use the X resource file syntax.
Quoted 1 line
If it does, it's not in any of the documentation I've ever seen.
It's in Ousterhout's Tcl/Tk book as well as in the Perl/Tk intro by Walsh. ;-) Tk calls this "option database" or similar. The only catch is that it needs to be explicitly loaded, see "optionReadfile" (at least that's what it's called in perl/tk).
Olaf
Quoted 3 lines · Eric S. Raymond
If there were already a library in ths stock Python distribution to digest .Xdefaults files I might consider this. Perhaps I'll write one.
No, please don't! .Xdefaults files as loaded by xrdb can contain cpp directives which can depend on the arguments given to xrdb ("xrdb -DBIGTERM .Xdefaults", for instance), so you can't assume that what you read from .Xdefaults is the user's setup, even if you emulate cpp. You also shouldn't assume that the user's HOME is on the machine where they loaded their resources from (suppose I start an X session on my workstation, then ssh over to a server and run CML2; it would then read server:~/.Xdefaults rather than workstation:~/.Xdefaults). It's much more sensible to use the normal X mechanisms for reading resources from the X server.
CML2 looks good---keep up the good work.
Signature · 1 line
Adam Sampson <[email protected]> <URL:http://azz.us-lot.org/>
Quoted 6 lines · Adam Sampson
Quoted 3 lines · Eric S. Raymond
If there were already a library in ths stock Python distribution to digest .Xdefaults files I might consider this. Perhaps I'll write one.
Quoted 10 lines
No, please don't! .Xdefaults files as loaded by xrdb can contain cpp directives which can depend on the arguments given to xrdb ("xrdb -DBIGTERM .Xdefaults", for instance), so you can't assume that what you read from .Xdefaults is the user's setup, even if you emulate cpp. You also shouldn't assume that the user's HOME is on the machine where they loaded their resources from (suppose I start an X session on my workstation, then ssh over to a server and run CML2; it would then read server:~/.Xdefaults rather than workstation:~/.Xdefaults). It's much more sensible to use the normal X mechanisms for reading resources from the X server.
The above absurdity is exactly why newer toolkits don't bother to support this config mechanism. There isn't any way to have the app support an "Edit --> Preferences --> Save" with this.
If the Python/Tk stuff (or whatever it is Eric is using) doesn't yet have a modern dotfile for this sort of thing, then we've just stumbled across a nice project.
Quoted 14 lines · Eric S. Raymond
CML2 NEWS
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.1.3:
* Freeze color changed from cyan to blue.
* Tom Rini's network-configuration patches.
* Better detection of set variables to be colored green.
* Minor resize and scrolling fixes in menuconfig.
* Fixed a rather nasty bug involving side-effect computation that showed up if you set, unset, and reset a symbol in a choices menu.
* In non-choice menus, select bar is now advanced after [ymn].
Quoted 1 line
Point release -- bug fixes and UI cleanups.
Whoops, I just tried out 1.1.3 using make xconfig, and now all the option labels are dark green, not just the ones set to y.
Thanks for changing the freeze color to blue. That is much more readable against the silver background for make xconfig.
Steven
Steven Cole <[email protected]>:
Quoted 2 lines
Whoops, I just tried out 1.1.3 using make xconfig, and now all the option labels are dark green, not just the ones set to y.
That's because they're set in your .config, dude!
Signature · 6 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry
Quoted 5 lines · Eric S. Raymond
Steven Cole <[email protected]>:
Quoted 2 lines
Whoops, I just tried out 1.1.3 using make xconfig, and now all the option labels are dark green, not just the ones set to y.
That's because they're set in your .config, dude!
Well, lets look at a snippet of the .config:
# CONFIG_BINFMT_SOM is not setCONFIG_BINFMT_AOUT=yCONFIG_BINFMT_ELF=yCONFIG_BINFMT_MISC=y
# CONFIG_SMP is not set
I just re-installed CML2 1.1.2, and it shows those options as you would expect, that is the ones set to y are green, and the "not set" ones are black. Well, except CONFIG_BINFMT_ELF which is black. Toggling it to n and then to y makes it green.
Re-installing CML2 1.1.3, I see all those options as green.
I can send you my whole .config if that would be useful.
Steven
Quoted 1 line · Eric S. Raymond
Release 1.1.3:
First I must say that versions 1.1.2, 1.1.3 are much faster than previous, I really cannot say that CML2 is in some way unusable for me. Good work!
Quoted 1 line
* Freeze color changed from cyan to blue.
Erm. Yes, in xconfig on _light background_ it is neat, but please but the cyan back for menuconfig, because the blue is invisible on black background. I dont think that anybody has problems with cyan in menuconfig.
Welcome to the world of GUI-programming...
Signature · 1 line
marko