All of lore.kernel.org
 help / color / mirror / Atom feed
From: Romain Lievin <roms@tilp.info>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: why the new config process is a *big* step backwards
Date: Mon, 14 Jan 2002 20:18:15 +0100	[thread overview]
Message-ID: <20020114191815.GA347@wanadoo.fr> (raw)
In-Reply-To: <3E23390F.29FF27D3@linux-m68k.org>

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 !"















  reply	other threads:[~2003-01-14 19:10 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
2002-01-14 19:18   ` Romain Lievin [this message]
     [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=20020114191815.GA347@wanadoo.fr \
    --to=roms@tilp.info \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zippel@linux-m68k.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.