[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0803042216030.7660@fbirervta.pbzchgretzou.qr>
Date: Tue, 4 Mar 2008 22:44:39 +0100 (CET)
From: Jan Engelhardt <jengelh@...putergmbh.de>
To: sam@...nborg.org
cc: Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...helsinki.fi>,
torvalds@...ux-foundation.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
mingo@...e.hu, vegard.nossum@...il.com
Subject: kernelprojects::menuconfig [was:Re: Google's Summer of Code?]
Hi Sam,
On Mar 4 2008 12:13, Andrew Morton wrote:
>"Pekka Enberg" <penberg@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists