On Sat, Apr 08, 2000 at 08:02:40AM +0000, Richard Taylor wrote:
> Ummm... how does your dselect work? Mine does pretty much what you've
> described above.
Not really; the whole thing is presented as a problem but it doesn't show
you clearly what it's done to try to resolve it, nor does it let you
accept/reject some of those changes in "blocks". Simple example.. I
selected gnome-admin for install, and I get a conflict screen which looks
approximately as follows:
EIOM Pri Section Package Description
_* Opt admin gnome-admin Gnome Admin Utilities (gulp and logview)
_* Opt libs libobgnome0 Objective-C - Gnome bindings
_* Opt libs libobgtk1 Objective-C - Gtk bindings
==
gnome-admin not installed - ; install (was: purge). Optional
gnome-admin depends on libobgnome0 (>= 1.0.40)
gnome-admin depends on libobgtk1 (>= 1.0.40)
It shows this if the cursor bar is over gnome-admin itself. The thing is,
it's not really clearly presented to you what dselect has decided. In this
case, it's just installing 2 more packages, but even that isn't clearly
obvious, despite the flags... to say nothing if the changes had been greater
(including recommends and conflicts). It's easier to read the changes if
dselect simply states something like the following:
gnome-admin requires the following extra packages to be installed:
libobgnome0 libobgtk1
it recommends the following, which I shall also install:
foo baz
gnome-admin conflicts with the following packages:
foobar1
The idea is to skip relatively unimportant details (most of the time) like
the priority, the section and possibly even the description.. at least from
the top half. You could make it so that you can go from package to package
in the above (ie. from libobgnome0 to libobgtk1 etc.) much like moving
between hyperlinks in lynx, and display the typical package info as (like in
the selection screen) as you do, underneath. Have one key (+/-, if you
like) that you can use to add/remove each proposed change. For each type,
if the user's change could be bad (remove dependency pkg, add conflict pkg)
it could warn and prompt the user for confirmation of whether they really
want to do that. Naturally, there would also be a single key to just accept
all dselect's proposed changes (like now).
And this is just a rough change that I think could present the choices
better and make it clearer what is happening... I haven't thought really
carefully about how it could be done, but I'm sure it could be done better..
other people might have other suggestions on how it could be improved.
Is dselect usable? Yes. But it could be better at abstracting away some
of the details that are typically not necessary and which just serve to
intimidate new users. Certainly that information should be available, but I
think a lot of it belongs in the package description window most of the
time. No need for flames BTW, this is just an opinion offered as food for
thought.
--
loki
[EMAIL PROTECTED]
Dare I disturb the universe? You bet I do! :)
