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.
--
<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
Eric S. Raymond wrote:
> 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.
--
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
On Monday 16 April 2001 15:42, Eric S. Raymond wrote:
> 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.
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]>:
> 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!
--
<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
On Monday 16 April 2001 16:06, Eric S. Raymond wrote:
> Steven Cole <[email protected]>:
> > 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 set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_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
On Mon, 16 Apr 2001, John Cowan wrote:
> Eric S. Raymond wrote:
>
> > 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]>:
> > 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.
--
<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/5
[esr]
> 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]>:
> 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.
--
<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
On Mon, Apr 16, 2001 at 05:42:23PM -0400, Eric S. Raymond wrote:
> 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!
> * 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...
--
marko
On Mon, Apr 16, 2001 at 11:20:48PM -0400, Eric S. Raymond wrote:
> Peter Samuelson <[email protected]>:
> > 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
> > 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.
> 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
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 [email protected]
One art/there is/no less/no more/All things/to do/with sparks/galore
--Douglas Hofstadter
On Mon, 16 Apr 2001, Eric S. Raymond wrote:
>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 available
>
>james rich <[email protected]>:
>> > 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.
Agreed.
>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]>:
> > 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*.
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.
--
<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)
Eric S. Raymond wrote:
> Other possibility: support only the 16 EGA colors by name.
Excellent idea!
> 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.
> 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.
> 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.
--
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]
> 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*....
> 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
"Eric S. Raymond" <[email protected]> writes:
> 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.
--
Adam Sampson <[email protected]> <URL:http://azz.us-lot.org/>
Adam Sampson writes:
> "Eric S. Raymond" <[email protected]> writes:
>> 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.
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.