linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Zippel <zippel@linux-m68k.org>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: why the new config process is a *big* step backwards
Date: Mon, 13 Jan 2003 23:09:19 +0100	[thread overview]
Message-ID: <3E23390F.29FF27D3@linux-m68k.org> (raw)
In-Reply-To: Pine.LNX.4.44.0301130743100.25468-100000@dell

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



  parent reply	other threads:[~2003-01-13 22:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-13 13:26 why the new config process is a *big* step backwards Robert P. J. Day
2003-01-13 15:32 ` Tomas Szepe
2003-01-13 15:37   ` Robert P. J. Day
2003-01-13 16:32   ` Werner Almesberger
2003-01-13 22:09 ` Roman Zippel [this message]
2002-01-14 19:18   ` Romain Lievin
     [not found] <20030113134017$1d68@gated-at.bofh.it>
2003-01-14 20:46 ` Kai Henningsen
2003-01-16 11:47 ` David Woodhouse

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=3E23390F.29FF27D3@linux-m68k.org \
    --to=zippel@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpjday@mindspring.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).