A proposal to improve dselect
David Gaudine wrote:
> ... maybe this has warped my attitude. But personally, I don't want
> to even *think* about installing X on a system until I've already
> installed everything else.
I absolutely agree. While an X based version of dselect might be
nice, what with the added utility of a mouse, scroll bars, and
possible multiple windows, the text based dselect must have the same
functionality and almost nearly the same ease of use.
John Henders just posted a very honest review of Debian 1.2 as
distributed on the Infomagic CD set. I think that some of the
problems he mentioned are specific to the Infomagic CD, and hopefully
the rest are being identified and will be cleaned up soon. (Should
Debian 1.2 have been called 1.2 beta?) More to the point, he
suggested several dselect improvements. Borrowing from his message
and from several others, here is a short list
I. Less clutter
A. Present packages like a folding editor, so the initial
presentation is quite compact.
B. Avoid showing the help screen every time the mode changes.
C. Distinguish between over abundant status messages, trivial
warnings, and serious errors.
1. Suppress all non-error status messages shown during
"Install" mode, optionally writing them to a file. (Not
only is it annoying to see the repeated messages, but when
I do get an error it scrolls off the screen and out of the
scroll back buffer before I can read it.)
2. Alternatively, let the non-error status messages overwrite
each other.
3. Alternatively, show the non-error status messages in a
separate window.
II. Friendlier, more intuitive interface
A. Exiting "Select" mode
1. The <enter> key should not Confirm and quit. (I find
this very counter intuitive.)
2. When you select exit/quit you should be given the option
of continuing or abandoning changes.
B. A new function for <enter>
1. At the very worst, the <enter> key should report on your
dependency/conflict status, without exiting.
2. <enter> (or some other key) should toggle (or cycle
through) the package markings. (In the latter case, it
couldn't jump and report any dependency/conflict
immediately upon key press.) It should also expand and
contract headings (as with the folding editor).
C. Mouse option (and even X)
1. Let it optionally run as a gpm client. The mouse could be
used to scroll (would scroll bars be appropriate even
without the mouse?), expand headings (as with the folding
editor), and toggle package markings.
2. Port it to X, with the same functionality as the souped up
text based version, but prettier (in some people's eyes).
III. General
A. Don't call dpkg for packages which don't need attention.
1. This might require a change in the way dselect and dpkg
interact.
2. Perhaps dselect will have to become a little smarter,
but doesn't it already know what is necessary to
determine if a package needs attention.
B. Allow a choice between several "recommended install sets".
1. For initial installation, have a minimum/base, standard,
and maximum "recommended install sets".
2. Allow for different "recommended install sets" in a
section. This is partly taken care of by priority, but
it should be more flexible.
3. Allow for user defined "recommended install sets". This
would be a boon for those who administer multiple
boxes. (Perhaps there could be a way to automate the
configuration of multiple machines as well.)
Often I go into dselect to find a package whose name I can't quite
remember, then view its description and check for dependencies, and
finally exit dselect and install the package by hand with dpkg -i.
That is just plain silly.
Perhaps dselect should be rebuilt from the ground up, and maybe
someone is already working on it, but that is not what I propose. I
think that it would be possible to take dselect as it is now and clean
it up considerably with a moderate amount of effort. Who is currently
maintaining dselect, and what projects are underway for its
improvement? Is it going to take one inspired individual to rewrite
all of dselect, or is this something that can be taken on by a small
to mid-size group?
Dselect is not only Debian's face to the world, it is also an
administrative tool which should be quick, powerful, and convenient
for even experienced administrators to use.
Unless a group like this is already in place, I propose that we form a
working group to initially hash out how dselect should be improved,
and then to actually implement those improvements.
Kirk Hilliard
Unix *is* user friendly -- it's just picky about who it makes friends
with. Let's make dselect more sociable.
Is this the best venue to continue this discussion, or should it be
taken elsewhere? Does debian-talk still exist?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: