LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jan Engelhardt <jengelh@computergmbh.de>
To: sam@ravnborg.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	torvalds@linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	mingo@elte.hu, vegard.nossum@gmail.com
Subject: kernelprojects::menuconfig [was:Re: Google's Summer of Code?]
Date: Tue, 4 Mar 2008 22:44:39 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0803042216030.7660@fbirervta.pbzchgretzou.qr> (raw)
In-Reply-To: <20080304121339.a3b2483f.akpm@linux-foundation.org>

Hi Sam,


On Mar 4 2008 12:13, Andrew Morton wrote:
>"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
>
>> I am also wondering if such a high profile
>> project as the kernel can get away with not having a "project ideas"
>> list which would make things real easy for the administrator(s)...
>
>http://kernelnewbies.org/KernelProjects
>

["""Update menuconfig to a modern ncurses look & feel

htop, aptitude, tig and other ncurses based programs has a more modern 
and effective look&feel than current menuconfig. Rip out all the 
lxdialog stuff and replace it with a ncurses based frontend that looks 
better and has more functionality."""]


I remember the last discussion about it, and I am still kinda in the 
position of "really?". I find the current menuconfig interface 
perfectable suitable.

I could not relate how menuconfig should look htop-style, because htop, 
for the most use, is just one screen with a process overview and a 
rather spartan "menu", should one decide to change some configuration 
options. Essentially it is a 4-column expand-to-the-right menu. No idea 
how to put it better.

aptitude. I only seen it very briefly since I do not use Debian. I can 
probably say the package selection in the OpenSolaris initial installer 
is similar, in other words, _all_ CONFIG options are listed in 
tree-style fashion in one window...

	> [ ] feature1
	  [ ] . . . feature2
	  [ ] . . . feature3
        > [ ] feature99

something like that. Anyway, I dislike the tree (expandable and 
contractable at will at the > points) — menuconfig seems superior
since, after entering a new submenu, just the options inside it are
displayed and nothing around it.

Then there are splitscreen approaches like qconfig/xconfig do, 
and I think I would not like that either for menuconfig; moving between 
two panels (one: the menu selection as a tree, the other: options for 
this submenu) is, kinda confusing in a text environment.

Of course there is a plus point for the tree-in-one (aptitude) approach 
in that searching for options/features is easier. The current menuconfig 
has a limited search function, for example, it will not take you to the 
option you searched but return to the menu you started the search from. 
Which means you have to repeatedly search for the option because you 
cannot remember the menus you have to go through to reach the option.

My stance: remain with the current menuconfig, and improve on the 
search(-and-jump) function.

Awaiting your counter-arguments and -opinions please.


thanks,
Jan

  parent reply	other threads:[~2008-03-04 21:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-04 18:45 Google's Summer of Code? Pekka Enberg
2008-03-04 19:35 ` Linus Torvalds
2008-03-04 19:55   ` Pekka Enberg
2008-03-04 20:05     ` Alexey Zaytsev
2008-03-04 20:23       ` Rik van Riel
2008-03-05 13:57         ` Giacomo A. Catenazzi
2008-03-05 15:38           ` Romano Giannetti
2008-03-06  8:36         ` Pekka Enberg
2008-03-04 20:13     ` Andrew Morton
2008-03-04 20:38       ` Andi Kleen
2008-03-05  2:01         ` text processing (Re: Google's Summer of Code?) Oleg Verych
2008-03-04 21:44       ` Jan Engelhardt [this message]
2008-03-05  6:09         ` kernelprojects::menuconfig [was:Re: Google's Summer of Code?] Willy Tarreau
2008-03-04 20:51 ` Google's Summer of Code? Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0803042216030.7660@fbirervta.pbzchgretzou.qr \
    --to=jengelh@computergmbh.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vegard.nossum@gmail.com \
    --subject='kernelprojects::menuconfig [was:Re: Google'\''s Summer of Code?]' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).