[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gdselect alpha 3 [libapt]



On Wed, 25 Nov 1998, Lalo Martins wrote:
> That's why I included a switch to omit the "Install it!" button
> :-) OTOH, I don't see why you would want to lose the other
> buttons. Even if you already have options elsewhere to inspect
> control files or view contents, I still think gdeb is a good
> place to have these. But I don't know, let's wait for these
> screenshots and see how you're doing things.
>

The worry I have is screen real estate; the tree view is unavoidably big,
even if I shrink it a lot (right now it is gratuitously big).
 
The advantage of a menu is that it's not on the screen...

> Yes, we know what the fields mean... but for average users that
> would be intimidating IMHO. As I said before, compare "dpkg -s"
> with the stuff in http://www.debian.org/Packages/
>

I do like those web pages. An unrelated concern: How can we get a
description of each section in Apt? Is it already there somehow?  

> I can't find it. I have read it when it was written some
> millenia ago, but I don't remember many of it. And I'm sure I
> have a copy somewhere, but... :-) [any URL around?]
>

http://www.debian.org/~wakkerma/apt-design2.txt
 
> /----------------------+-----------------\
> |                      |                 |
> |    your  package     |                 |
> |     tree widget      |      gdeb       |
> |                      |                 |
> |                      +-----------------+
> |                      |    a box with   |
> |                      | buttons for the |
> |                      |     actions     |
> \----------------------+------------------/
> 

Hmm. Whenever possible, I would prefer to have the actions and the view
merged. For example, a check box for delete/keep/install is simultaneously
an indicator of current state and something you can use to change state.
Whenever possible I think we should do this, since it is both nice to use
and reduces screen usage.

The only actions other than install would be to view the package's
scripts, list of files in the package, etc. - right? I think these are
sort of obscure features few people will use often, even experts. So I'd
advocate sticking them on a menu somwhere, popup or otherwise.

(A side issue is whether the package info goes to the right or above the
tree.)
 
> The notebook is (again IMHO) a better sollution than the paned
> window and the option of configuring some of the info out.
> Basically, it displays the stuff the user wants to know by
> default [description, priority, section, and of course the sizes
> whch are very important for most people ;-)] and you have to use
> the notebook tabs to see more.
> 

I think there are two disadvantages to the notebook: one, the tabs take up
a lot of space; two, you can't see all the info at once. The key issue is
whether all the info can fit on the screen without a notebook. If it can,
that's better. If it can't, a notebook is a nice solution. I don't know
how this will play out.

> > However the buttons to view all the scripts and package
> > contents should be moved to gnome-apt's popup menu, which
> > already has a lot of operations on the currently selected
> > package.
> 
> UI-wise, I firmly disagree. Popups are convenient but
> counter-intuitive. They're nice to have, but should never be the
> only way of doing something.
>

Perhaps so. We can consider moving all this stuff to the menu bar instead,
and have the popup be a simple clone of the menu bar for those too lazy to
move the mouse. The current popup/menubar distinction doesn't make too
much sense anyway.
 
> Again I think that hidind it in the second page of the bookmark
> is a good solution, but we can get rid of it easily if most
> people want it gone. However, I would think that the tree view
> would display depends, recommends and suggests, while the
> package view would display all relationships.
>

Good point.
 
Something to keep in mind: the "unifying theme" of this interface is the
notion of the "currently selected package." The current package will be
highlighted in the tree view, its info will be displayed next to the tree,
and package-related menu items (in the "package" menu) will operate on the
current package. I think the menus in Wichert's document may need
rearranging with this in mind. 

Havoc






Reply to: