Re: why the new config process is a *big* step backwards

Re: why the new config process is a *big* step backwards

[Romain Lievin]

On Mon, Jan 13, 2003 at 11:09:19PM +0100, Roman Zippel wrote:
> Hi,
> 
> >   at least in the old "make xconfig", i could bring up two
> > children dialogs at a time.  perhaps i want to examine/configure
> > both "Block devices" and "Filesystems" at the same time, since
> > there are some related features (loopback device support under
> > Block devices lets me mount filesystem images).  under the
> > new scheme, this is impossible (unless there's a trick or
> > feature i haven't found).
> 
> Have you found the full tree mode?
> I'm thinking about the option to open a submbenu in its own window, but
> it will not be the default. I really hate it when a program thinks it
> has to open a new window for everything.

Well, popup dialogs are very annoying...
The current system has enough windows for dislaying the important informations
(hierarchy, help, informations).

> 
> >   and that option window is just confusing.  given that we
> > already have +/- expand/collapse icons, and checkboxes for
> > selection, it just makes things messier to have these submenu
> > boxes with the internal triangle.  and once it takes you to
> > that submenu, is it really painfully obvious how you back up
> > one level?  (the arrow icon in the tool bar?)
> 
> Offering too many options at once is not good either, as then you have
> the choice that you must expand lots of submenus until you find, what
> you need or you have a huge list of options. The current window is a
> compromise, which doesn't show too much and already has everything
> expanded. If possible I would omit the +/- icons, but it's not possible
> without reimplementing the whole widget.

To my mind, the current configuration system provides enough options (ie views)
for most of the users without having a program too complex/big...
Moreover, I think that the Split & Tree views are very practictal.

The +/- icons (even if they are not available in the GTK+ version) allow you
to change an option without displaying the other columns.
It may be very useful if you have a small screen size. You don't have to scroll
the window...

> 
> bye, Roman
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Romain.
-- 
Romain Lievin, aka 'roms'  	<roms@tilp.info>
The TiLP project is on 		<http://www.ti-lpg.org>
"Linux, y'a moins bien mais c'est plus cher !"

why the new config process is a *big* step backwards

[Robert P. J. Day]

  (apologies to those who are thoroughly sick of this topic, but
i'm now firmly convinced that i don't much care for the new
config process, and i'm curious as to whether it's just me.
Answer: probably.)

  IMHO, the new config process (and i'll restrict myself to talking
about the graphical "make xconfig" process here) not only doesn't
improve substantially over the old one, but is actually worse in 
a number of places.  where to start?

  first, the hierarchical structure of the options in the left
window (i'm going to make up names and call these the "menu window",
"option window" and "help window") is non-intuitive, in that the
top-level selection will bring up a set of selectable options,
while submenus will *also* bring up options.

  example:  Power management options.  if i select that menu
option explicitly, i get options including APM in the option
window.  but if i expand that option, i can select the submenu
"ACPI Support", for further options.  this is confusing --
it's analogous to a directory having files both directly inside
it *and* within a sub-structure.  

  this is inconsistent with other common things people are
familiar with -- in the pine mailer, for example, you can't
use a folder both for storing files *and* for having subfolders.
and think about bookmarks in a browser (a model i wish the new
config process had followed).

  the current design is messy since it suggests that some
options belong strictly to the top level, while others belong
to more specialized sub levels.  if that's the case, then
the menu window should contain something like:

[+] Power management options (APM, ACPI)
      Basic APM options
      ACPI Support

(obviously, this would apply to *all* entries in the menu
window thave have submenus.)

  but wait, you say, there's an advantage to this approach.
it means i can, with one click, get to the more common settable
options, rather than needing to expand the top level menu.
so we get to my second complaint.

  there's no reason to not have checkboxes *right* *in*
the menu window, so i can see *immediately* whether i have
entire submenu options selected.

  consider "IrDA (infrared) support".  from the menu window,
there's no way to tell if i have this selected.  instead, i
must select that option, get it's option window displayed, and
only then can i see/select/deselect *all* of IrDA in one fell
swoop.  (of course, the same is true of submenus where, e.g.,
under Networking support, i can only deselect all of 
"Ethernet 1000 Mbit" by first selecting that option, getting
its menu, then turning it off at the top.)
 
  this is hideously uninformative, since it's impossible to tell
at a glance what entire submenus are selected or not.  why
*shouldn't* i be able to see, with one look, that my current
configuration is not selecting Plug and Play, SCSI, Amateur
Radio, IrDA, IDSN, Power Management and Bluetooth?  adding
selection checkboxes to top-level entries in the menu window
would make this trivial, and it's one area that the previous
configuration program fell down as well.  it's disappointing
that this was not addressed.

  my third complaint represents where the new config process is
actually *worse* than the previous.  the fact that there is
a single menu window and a single option window makes it
impossible to work in detail in more than one part of the
main menu at a time (assuming i haven't overlooked some neat
feature of this new process).

  at least in the old "make xconfig", i could bring up two
children dialogs at a time.  perhaps i want to examine/configure
both "Block devices" and "Filesystems" at the same time, since
there are some related features (loopback device support under
Block devices lets me mount filesystem images).  under the
new scheme, this is impossible (unless there's a trick or
feature i haven't found).

  and that option window is just confusing.  given that we
already have +/- expand/collapse icons, and checkboxes for
selection, it just makes things messier to have these submenu
boxes with the internal triangle.  and once it takes you to
that submenu, is it really painfully obvious how you back up
one level?  (the arrow icon in the tool bar?)

  frankly, i would like to see the option window disappear
entirely.  i see no need to have more than two frames --
a menu window with expandable/collapsible choices, where
i can select/deselect entire chunks with a click, where it's
obvious at a glance which parts are deselected, and where
i can expand more than one part of the top-level menu to
configure more than one set of options at a time.

  (this would be even more practical if the number of top-level
entries in the menu window was reduced.  i mean, is it really
necessary to have separate top-level entries for MTD, Fusion
MPT and related selections?  why not just a top-level entry
for some kind of all-encompassing "Device support"?  i know,
that's a bad name, but you get the idea.)

  anyway, i've rambled enough.  time for coffee.

rday

Re: why the new config process is a *big* step backwards

[Tomas Szepe]

> [rpjday@mindspring.com]
> 
>   (apologies to those who are thoroughly sick of this topic, but
> i'm now firmly convinced that i don't much care for the new
> config process, and i'm curious as to whether it's just me.
> Answer: probably.)

Robert,

please study scripts/kconfig/*, not how one particular frontend is.
The new kernel configurator is actually a big improvement over the
traditional stuff we used to have up to 2.4.  Okay, it is a fact that
xconfig is far from great, but that doesn't matter -- the important
thing is Kconfig provides a clean, generic system for the actual kernel
configuration.  As I already pointed out a fortnight ago or so, the
only config frontend likely to stay in linux.tar in the long run is
menuconfig, serving as a reference to userland people who are certain
to come up with heaps of different Kconfig frontends (that is when
2.6 ships I guess).

If you need a nifty graphical frontend right away, I suggest you
go ahead and write the first off-tree xconfig.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: why the new config process is a *big* step backwards

[Robert P. J. Day]

On Mon, 13 Jan 2003, Tomas Szepe wrote:

> Robert,
> 
> please study scripts/kconfig/*, not how one particular frontend is.
> The new kernel configurator is actually a big improvement over the
> traditional stuff we used to have up to 2.4.  Okay, it is a fact that
> xconfig is far from great, but that doesn't matter -- the important
> thing is Kconfig provides a clean, generic system for the actual kernel
> configuration.  As I already pointed out a fortnight ago or so, the
> only config frontend likely to stay in linux.tar in the long run is
> menuconfig, serving as a reference to userland people who are certain
> to come up with heaps of different Kconfig frontends (that is when
> 2.6 ships I guess).
> 
> If you need a nifty graphical frontend right away, I suggest you
> go ahead and write the first off-tree xconfig.

ok, point taken.  i'll take a look at it, thanks.

rday

Re: why the new config process is a *big* step backwards

[Werner Almesberger]

Tomas Szepe wrote:
> If you need a nifty graphical frontend right away, I suggest you
> go ahead and write the first off-tree xconfig.

... and as a starting point, perhaps something that looks like
ftp://icaftp.epfl.ch/pub/linux/local/scend/scend-0.5.tar.gz
(when compiling, change "msg" to "dummy" where it complains)
might not be all that bad.

(Okay, it's text-based, doesn't know about modules, uses its own
language, and comes with an example for a kernel as recent as
1.1.80 :-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: why the new config process is a *big* step backwards

[Roman Zippel]

Hi,

"Robert P. J. Day" wrote:

>   first, the hierarchical structure of the options in the left
> window (i'm going to make up names and call these the "menu window",
> "option window" and "help window") is non-intuitive, in that the
> top-level selection will bring up a set of selectable options,
> while submenus will *also* bring up options.

The option window will likely get a back button.
How the option window works might not be obvious, but I don't think it's
that difficult to find out how it works, but I'm always open to
suggestion to improve this.

>   example:  Power management options.  if i select that menu
> option explicitly, i get options including APM in the option
> window.  but if i expand that option, i can select the submenu
> "ACPI Support", for further options.  this is confusing --
> it's analogous to a directory having files both directly inside
> it *and* within a sub-structure.

The problem here is that the Kconfig files weren't directly written for
the new config tool, so it has to make the best out of it. There is of
course enough room for improvement.

>   there's no reason to not have checkboxes *right* *in*
> the menu window, so i can see *immediately* whether i have
> entire submenu options selected.

A patch to make this possible is available, but it needs a bit more
work.

>   at least in the old "make xconfig", i could bring up two
> children dialogs at a time.  perhaps i want to examine/configure
> both "Block devices" and "Filesystems" at the same time, since
> there are some related features (loopback device support under
> Block devices lets me mount filesystem images).  under the
> new scheme, this is impossible (unless there's a trick or
> feature i haven't found).

Have you found the full tree mode?
I'm thinking about the option to open a submbenu in its own window, but
it will not be the default. I really hate it when a program thinks it
has to open a new window for everything.

>   and that option window is just confusing.  given that we
> already have +/- expand/collapse icons, and checkboxes for
> selection, it just makes things messier to have these submenu
> boxes with the internal triangle.  and once it takes you to
> that submenu, is it really painfully obvious how you back up
> one level?  (the arrow icon in the tool bar?)

Offering too many options at once is not good either, as then you have
the choice that you must expand lots of submenus until you find, what
you need or you have a huge list of options. The current window is a
compromise, which doesn't show too much and already has everything
expanded. If possible I would omit the +/- icons, but it's not possible
without reimplementing the whole widget.

bye, Roman

Re: why the new config process is a *big* step backwards

[David Woodhouse]

kaih@khms.westfalen.de said:
> >   this is inconsistent with other common things people are
> > familiar with -- in the pine mailer, for example, you can't
> > use a folder both for storing files *and* for having subfolders.
> > and think about bookmarks in a browser (a model i wish the new
> > config process had followed).

> Strange. Filesystems (which everyone should be familiar with)
> certainly do   this, and so does (for example) Pegasus Mail with IMAP
> folders ...

> I think Pine and bookmarks are faulty here.

Nah. Pine can do folders containing both mail and subfolders just fine.


--
dwmw2

Re: why the new config process is a *big* step backwards

[Kai Henningsen]

rpjday@mindspring.com (Robert P. J. Day)  wrote on 13.01.03 in <20030113134017$1d68@gated-at.bofh.it>:

>   (apologies to those who are thoroughly sick of this topic, but
> i'm now firmly convinced that i don't much care for the new
> config process, and i'm curious as to whether it's just me.
> Answer: probably.)

Probably.

>   IMHO, the new config process (and i'll restrict myself to talking
> about the graphical "make xconfig" process here) not only doesn't

Hmm. The old xconfig was so unusable I haven't used anything but  
menuconfig for years ...
>
>   first, the hierarchical structure of the options in the left
> window (i'm going to make up names and call these the "menu window",
> "option window" and "help window") is non-intuitive, in that the
> top-level selection will bring up a set of selectable options,
> while submenus will *also* bring up options.
>
>   example:  Power management options.  if i select that menu
> option explicitly, i get options including APM in the option
> window.  but if i expand that option, i can select the submenu
> "ACPI Support", for further options.  this is confusing --
> it's analogous to a directory having files both directly inside
> it *and* within a sub-structure.
>
>   this is inconsistent with other common things people are
> familiar with -- in the pine mailer, for example, you can't
> use a folder both for storing files *and* for having subfolders.
> and think about bookmarks in a browser (a model i wish the new
> config process had followed).

Strange. Filesystems (which everyone should be familiar with) certainly do  
this, and so does (for example) Pegasus Mail with IMAP folders ...

I think Pine and bookmarks are faulty here. (Especially as in the current  
Mozilla, you *can* have folders-as-bookmarks but you can't easily switch  
from one behaviour to the other, plus Mozilla itself sometimes gets  
confused. Also, Open File insists on files even though Mozilla can handle  
local directories just fine ...)

>   the current design is messy since it suggests that some
> options belong strictly to the top level, while others belong
> to more specialized sub levels.

Well, that's certainly how it always was with menuconfig.

MfG Kai