Hi,
I gave nconfig a try, and here are a few suggestive points:
- provide the same color scheme as menuconfig
- I get a visual glitch (see Exhibit A below) in General setup (patch
slapped onto 2.6.32); the left frame part is missing.
- For symbol info, it would be cool if it wrapped the "Selected by"
line (menuconfig also "suffers" from this), because that one can
get exceptionally long and awkward to scroll.
- I certainly like F4-Config-ShowAll :) but it has some glitches
interfering near ARCH_DEFCONFIG (see Exhibit B).
----(Exhibit A)
.config - Linux Kernel v2.6.32 Configuration
┌── General setup ───────────────────────────────────────────────────────────┐
│ │
[*] Prompt for development and/or incomplete code/drivers │
() Local version - append to kernel release │
[ ] Automatically append version information to the version string │
[*] Support for paging of anonymous memory (swap) │
[*] System V IPC │
[*] POSIX Message Queues │
[*] BSD Process Accounting │
[ ] BSD Process Accounting version 3 file format │
[*] Export task/process statistics through netlink (EXPERIMENTAL) │
[*] Enable per-task delay accounting (EXPERIMENTAL) │
[*] Enable extended accounting over taskstats (EXPERIMENTAL) │
[*] Enable per-task storage I/O accounting (EXPERIMENTAL) │
[*] Auditing support │
[*] Enable system-call auditing support │
RCU Subsystem ---> │
< > Kernel .config support │
(17) Kernel log buffer size (16 => 64KB, 17 => 128KB) │
[*] Group CPU scheduler │
│ │
│ │
└F1Help─F2Symbol Info─F3Instructions─F4Config─F5Back─F6Save─F7Load─F8Exit────┘
----
----(Exhibit B)
┌── Linux Kernel Configuration ──────────────────────────────────────────────┐
│ │
│ XXX 64-bit kernel │
│ XXX SPARC │
│ XXX SPARC32 │
│ XXX SPARC64 │
│ XXXch/sparc/configs/sparc64_defconfig) ARCH_DEFCONFIG │
│ XXX) BITS │
│ XXX GENERIC_TIME │
...
----
Jan Engelhardt wrote:
> - For symbol info, it would be cool if it wrapped the "Selected by"
> line (menuconfig also "suffers" from this), because that one can
> get exceptionally long and awkward to scroll.
Vadim Bendebury recently sent a patch to address this in menuconfig.
Once done, it should be trivial to apply it to nconfig, too. See
http://patchwork.kernel.org/patch/66287/
Michal
Hello.
On Fri, Dec 11, 2009 at 9:55 PM, Jan Engelhardt <[email protected]> wrote:
> Hi,
>
>
> I gave nconfig a try, and here are a few suggestive points:
10x ;)
> - provide the same color scheme as menuconfig
As far as colrs are involved, I think it is best to not impose any
color scheme. You can never satisfy everyone, and will get into
endless fights about which is best. I believe the current approach in
nconfig works best, as I am using the default terminal colors for the
main body of text (menus, help text, etc), and only use colors for
emphasis (headings, boxes, etc). This is based on the belief that
users have already chosen the colors which work best for them, and are
already using them in their teminal's config.
> - I get a visual glitch (see Exhibit A below) in General setup (patch
> ?slapped onto 2.6.32); the left frame part is missing.
I cannot reproduce this. Can you provide some more details? (e.g.,
which terminal, $LINES, $COLUMNS, $TERM)
> - For symbol info, it would be cool if it wrapped the "Selected by"
> ?line (menuconfig also "suffers" from this), because that one can
> ?get exceptionally long and awkward to scroll.
I took a look at the patch by Vadim Bendebury, should be easy to adapt nconfig.
> - I certainly like F4-Config-ShowAll :) ?but it has some glitches
> ?interfering near ARCH_DEFCONFIG (see Exhibit B).
Thanks for catching this. It is a by-product of the code for
presenting everything inside a single menu. Easily fixed in the next
version. By the way, is anyone using this option at all? It would much
simplify the code if I did not have to support the one giant menu
option.
Chhers,
Nir.
On Sunday 2009-12-13 08:23, Nir Tzachar wrote:
>On Fri, Dec 11, 2009 at 9:55 PM, Jan Engelhardt <[email protected]> wrote:
>> Hi,
>>
>>
>> I gave nconfig a try, and here are a few suggestive points:
>
>10x ;)
Ten times what?
>> - provide the same color scheme as menuconfig
>
>As far as colrs are involved, I think it is best to not impose any
>color scheme. You can never satisfy everyone, and will get into
>endless fights about which is best.
Well, menuconfig seems to have had the least fights. There was exactly
one color scheme imposed, and that did not change for years; when themes
were added, not much happened. There was a bit of discussion and
submissions about themes (including myself), but in the end, it was
sort-of agreed upon that four were enough. And they seem to work for
everybody.
>I believe the current approach in nconfig works best, as I am using
>the default terminal colors for the main body of text (menus, help
>text, etc), and only use colors for emphasis (headings, boxes, etc).
No sorry. Black-on-blue does not work very much, for the physical fact
that blue is recognized as faint. Let me put in some numbers (30,59,11%
are the common RGB weighting for grayscale/luminance)
Blue: Effective Lum:
- xterm standard (#0000EE): 26.18
- VGA standard (#0000AA): 18.70
Cyan:
- VGA (#00AAAA) 119.00
So you see why Midnight Commander, htop, etc. all use Black-on-Cyan for
their Fn keybar instead of Blue.
>This is based on the belief that users have already chosen the colors
>which work best for them, and are already using them in their teminal's
>config.
>
>> - I get a visual glitch (see Exhibit A below) in General setup (patch
>> slapped onto 2.6.32); the left frame part is missing.
>
>I cannot reproduce this. Can you provide some more details? (e.g.,
>which terminal, $LINES, $COLUMNS, $TERM)
xterm -bg black -fg gray -geometry 80x25
>> - I certainly like F4-Config-ShowAll :) but it has some glitches
>> interfering near ARCH_DEFCONFIG (see Exhibit B).
>
>Thanks for catching this. It is a by-product of the code for
>presenting everything inside a single menu. Easily fixed in the next
>version. By the way, is anyone using this option at all? It would much
>simplify the code if I did not have to support the one giant menu
>option.
Well nconfig is the first to provide that option. (Note: I don't use
gconfig or xconfig, so I cannot tell if they have something like that.)
So to see whether there is use, you would have to wait a number of
kernel releases that have nconfig integrated.
> >As far as colrs are involved, I think it is best to not impose any
> >color scheme. You can never satisfy everyone, and will get into
> >endless fights about which is best.
>
> Well, menuconfig seems to have had the least fights. There was exactly
> one color scheme imposed, and that did not change for years; when themes
> were added, not much happened. There was a bit of discussion and
> submissions about themes (including myself), but in the end, it was
> sort-of agreed upon that four were enough. And they seem to work for
> everybody.
I also would like the current (menuconfig) defautl color scheme to be used.
> >Thanks for catching this. It is a by-product of the code for
> >presenting everything inside a single menu. Easily fixed in the next
> >version. By the way, is anyone using this option at all? It would much
> >simplify the code if I did not have to support the one giant menu
> >option.
>
> Well nconfig is the first to provide that option. (Note: I don't use
> gconfig or xconfig, so I cannot tell if they have something like that.)
> So to see whether there is use, you would have to wait a number of
> kernel releases that have nconfig integrated.
We already have:
Optional personality available
. ------------------------------
. If you prefer to have all of the kernel options listed in a single
. menu, rather than the default multimenu hierarchy, run the menuconfig
. with MENUCONFIG_MODE environment variable set to single_menu. Example:
.
. make MENUCONFIG_MODE=single_menu menuconfig
.
. <Enter> will then unroll the appropriate category, or enfold it if it
. is already unrolled.
. Note that this mode can eventually be a little more CPU expensive
. (especially with a larger number of unrolled categories) than the
. default mode.
But I do not think it is much used.
Sam
On Sunday 2009-12-13 12:55, Sam Ravnborg wrote:
>
>> >Thanks for catching this. It is a by-product of the code for
>> >presenting everything inside a single menu. Easily fixed in the next
>> >version. By the way, is anyone using this option at all? It would much
>> >simplify the code if I did not have to support the one giant menu
>> >option.
>>
>> Well nconfig is the first to provide that option. (Note: I don't use
>> gconfig or xconfig, so I cannot tell if they have something like that.)
>> So to see whether there is use, you would have to wait a number of
>> kernel releases that have nconfig integrated.
>
>We already have:
>Optional personality available
> . ------------------------------
> . If you prefer to have all of the kernel options listed in a single
> . menu, rather than the default multimenu hierarchy, run the menuconfig
> . with MENUCONFIG_MODE environment variable set to single_menu. Example:
> .
> . make MENUCONFIG_MODE=single_menu menuconfig
I think the discussion went about "show hidden symbols" rather than
"show everything in a single menu". Or at least that was my intention -
sorry for any confusion.
On Sun, Dec 13, 2009 at 03:25:14PM +0100, Jan Engelhardt wrote:
>
> On Sunday 2009-12-13 12:55, Sam Ravnborg wrote:
> >
> >> >Thanks for catching this. It is a by-product of the code for
> >> >presenting everything inside a single menu. Easily fixed in the next
> >> >version. By the way, is anyone using this option at all? It would much
> >> >simplify the code if I did not have to support the one giant menu
> >> >option.
> >>
> >> Well nconfig is the first to provide that option. (Note: I don't use
> >> gconfig or xconfig, so I cannot tell if they have something like that.)
> >> So to see whether there is use, you would have to wait a number of
> >> kernel releases that have nconfig integrated.
> >
> >We already have:
> >Optional personality available
> > . ------------------------------
> > . If you prefer to have all of the kernel options listed in a single
> > . menu, rather than the default multimenu hierarchy, run the menuconfig
> > . with MENUCONFIG_MODE environment variable set to single_menu. Example:
> > .
> > . make MENUCONFIG_MODE=single_menu menuconfig
>
> I think the discussion went about "show hidden symbols" rather than
> "show everything in a single menu". Or at least that was my intention -
> sorry for any confusion.
I did not check what nconfig does exactly - I just assumed it was
the single_menu mode.
I know several people has requested the possibility to see all
ie. also hidden) symbols before.
Sam
>> I think the discussion went about "show hidden symbols" rather than
>> "show everything in a single menu". Or at least that was my intention -
>> sorry for any confusion.
>
> I did not check what nconfig does exactly - I just assumed it was
> the single_menu mode.
> I know several people has requested the possibility to see all
> ie. also hidden) symbols before.
>
> ? ? ? ?Sam
>
nconfig derives the single menu mode from menuconfig. However, it
makes the code rather hard to maintain/understand, and if there is no
use for this feature, I would like to remove it.
Nir.
>>10x ;)
>
> Ten times what?
Thanks...
>>> - provide the same color scheme as menuconfig
>>
>>As far as colrs are involved, I think it is best to not impose any
>>color scheme. You can never satisfy everyone, and will get into
>>endless fights about which is best.
>
> Well, menuconfig seems to have had the least fights. There was exactly
> one color scheme imposed, and that did not change for years; when themes
> were added, not much happened. There was a bit of discussion and
> submissions about themes (including myself), but in the end, it was
> sort-of agreed upon that four were enough. And they seem to work for
> everybody.
>
>>I believe the current approach in nconfig works best, as I am using
>>the default terminal colors for the main body of text (menus, help
>>text, etc), and only use colors for emphasis (headings, boxes, etc).
>
> No sorry. Black-on-blue does not work very much, for the physical fact
> that blue is recognized as faint. Let me put in some numbers (30,59,11%
> are the common RGB weighting for grayscale/luminance)
>
> ?Blue: ? ? ? ? ? ? ? ? ? ? ? Effective Lum:
> ?- xterm standard (#0000EE): 26.18
> ?- VGA standard (#0000AA): ? 18.70
> ?Cyan:
> ?- VGA (#00AAAA) ? ? ? ? ? ? 119.00
>
> So you see why Midnight Commander, htop, etc. all use Black-on-Cyan for
> their Fn keybar instead of Blue.
I'll go along with you, but only as fat as the highlights are
concerned. I will oppose any kind of color theme for the main body of
text, as it will just lead to arguments about readability, etc., which
I feel no one would win but the loudest complainer. Again, I believe
it is best to make use as much as possible of the colors the user has
picked for her terminal, as she had already made the best choice for
_her_.
>>> - I get a visual glitch (see Exhibit A below) in General setup (patch
>>> ?slapped onto 2.6.32); the left frame part is missing.
>>
>>I cannot reproduce this. Can you provide some more details? (e.g.,
>>which terminal, $LINES, $COLUMNS, $TERM)
>
> xterm -bg black -fg gray -geometry 80x25
I cannot reproduce this on any of my systems. Any idea how to
proceed?? Can you also send a snapshot?
On Monday 2009-12-14 06:41, Nir Tzachar wrote:
>>>> - I get a visual glitch (see Exhibit A below) in General setup (patch
>>>> slapped onto 2.6.32); the left frame part is missing.
>>>
>>>I cannot reproduce this. Can you provide some more details? (e.g.,
>>>which terminal, $LINES, $COLUMNS, $TERM)
>>
>> xterm -bg black -fg gray -geometry 80x25
>
>I cannot reproduce this on any of my systems. Any idea how to
>proceed?? Can you also send a snapshot?
>
Add this to the top of arch/x86/Kconfig:
config VERY_LONG_CONFIGURATION_OPTION
bool "With a very long long description, you see where this is going"
to reproduce the effect on ARCH=x86.
Please try this patch. It should solve both of the problems you reported.
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 8c56150..cab6bb0 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -984,7 +984,7 @@ static void build_conf(struct menu *menu)
break;
default:
tmp = 2 + strlen(sym_get_string_value(sym));
- item_make(menu, 's', "(%s)",
+ item_make(menu, 's', " (%s)",
sym_get_string_value(sym));
tmp = indent - tmp + 4;
if (tmp < 0)
@@ -1072,8 +1072,8 @@ static void show_menu(const char *prompt, const
char *instructions,
/* position the menu at the middle of the screen */
scale_menu(curses_menu, &maxy, &maxx);
- maxx = min(maxx, mwin_max_cols);
- maxy = mwin_max_lines-1;
+ maxx = min(maxx, mwin_max_cols-2);
+ maxy = mwin_max_lines-2;
menu_window = derwin(main_window,
maxy,
maxx,
On Mon, Dec 14, 2009 at 2:26 PM, Jan Engelhardt <[email protected]> wrote:
> On Monday 2009-12-14 06:41, Nir Tzachar wrote:
>
>>>>> - I get a visual glitch (see Exhibit A below) in General setup (patch
>>>>> ?slapped onto 2.6.32); the left frame part is missing.
>>>>
>>>>I cannot reproduce this. Can you provide some more details? (e.g.,
>>>>which terminal, $LINES, $COLUMNS, $TERM)
>>>
>>> xterm -bg black -fg gray -geometry 80x25
>>
>>I cannot reproduce this on any of my systems. Any idea how to
>>proceed?? Can you also send a snapshot?
>>
>
> Add this to the top of arch/x86/Kconfig:
>
> config VERY_LONG_CONFIGURATION_OPTION
> ? bool "With a very long long description, you see where this is going"
>
> to reproduce the effect on ARCH=x86.
>
On Monday 2009-12-14 14:45, Nir Tzachar wrote:
>Please try this patch. It should solve both of the problems you reported.
Yes it does.
(Besides that it does not apply. Gmail whitespace
problems again?)