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

Re: apt 0.3.0



On Fri, 29 Jan 1999, Daniel Burrows wrote:
> 
>   * When apt is started, it defaults to grouping by letter.  This is almost
>    useless; any of the other grouping mechanisms would be much better.
>

OK, consensus here. Which do you think should be default?
    
>   * Also, it would be nice to have several levels of grouping, so that I could
>    group packages by priority, then by section, and then by status, or by
>    status, then by priority, then by section, etc.
>    

Hmm... yes. The tree view needs a rewrite. I've grafted so many things
onto the code that it's a real mess. Anyway, this will take a while.

>   * I think that maybe (for example) contrib/comm, comm/, and non-free/comm
>    should all be in a hierarchical structure under comm when grouping by
>    section (so you have comm/, comm/contrib, and comm/non-free).  This was
>    one of the more annoying aspects of dselect, and it's unfortunate that
>    apt seems to have preserved it.
>    

This will also require the above multilevel-folder change. Good idea
though.

>   * I think that single-clicking on the plus and minus signs in the tree should
>    expand the tree a level, as occurs with (almost) every other GUI program in
>    the world.
> 

Will fix.

>   * The status and priority filters should either not be drop-down menus
>    (put them to the right of the package listing or in popup toolbars) or else
>    use the tearoff menu feature of GTK+.  Users will likely often want to set
>    a number of settings in these menus, and having to click on the drop-down
>    box each time is a nuisance.
>    

Tearoff menus sounds like a good idea to me. I don't want to put them in
the main window since it's already cramped. 

>   * Running the new apt on an old installation causes all packages to be
>    displayed as kept, with no way to change them to installed.
>    

??? - are you sure? I'm not sure I see what you mean.

>   * Use tooltips.  There are a lot of non-obvious things in the interface
>    (D, K, I?  Are those state markers?  Why are they apparently not used?  Why
>    can't I even toggle them off in the Columns menu?)
>     (A better thing would be to eliminate the non-obvious things, of course)
>

I'll look into tooltips; the standard Gtk ones won't work because none of
those elements are widgets, and tooltips attach to widgets.

DKI is Delete Keep Install; you can't turn them off because they are the
whole point of the application. 
 
>   * I somehow accidentally marked a package (apt, no less) for deletion by
>    clicking on an innocuous-looking part of the window and now I can't
>    set it for install/keep again.
> 

You must have clicked in the Delete column... if not then it's a bug.

>   * As a result of that, gnome-apt is broken, but the status "would be
>    broken" overlaps with the section "admin" to its right.
>

I can't avoid this without sizing every column to fit the largest
contained text; this would be slow, and also annoying, IMO.

(However, "Would be broken" should be clipped, rather than extending on
top of admin. If it isn't that's a bug.)
 
>   * Why is the package state managed with a bunch of toggles?  It seems to me
>    that a radio list would be better (it can't be set to be installed, removed,
>    and kept simultaneously)  Also, there should be a way to change the package
>    state from the list, at least for the most common cases (maybe put a set
>    of radio buttons to the left of the list or some columns with a check mark
>    which appears in the column corresponding to the item's current state)
> 

That's what DKI are!

Many people have suggested radio items instead of toggles. I will give in
eventually.

>   * I think that the dependancies should be listed as a tab on the left.

They will also be there, eventually. One of those blank pages.

>    I'd expect the subtree of a package to be the contents of the package.

You mean a list of files in it? Is that useful?

>    Also, the icons should be either replaced or supplemented with a verbal
>    description of its meaning. (The slashed O must be..Conflicts?  And the
>    R is Replaces I guess.  And the other funny diagonal thing must be Keep since
>    since that's what all my packages are set to)
> 

Documentation will help here. Verbal description in the tree view takes up
too much space.

I'm thinking a little dialog with each image and an explanation.

>    Aside from the fact that I can't change any package's status except to remove
>   it (I can't even detoggle Remove) and the fact that all my packages are listed
>   as Keep (or is this Correct Behavior?),

Ah, I see the confusion.

I should rename those from Toggle. It isn't really Toggle, because they
are only active if they are not already set. It is really Set. i.e., set
to be deleted, set to be kept, set to be installed.

It is correct that they are all kept, because you haven't asked to delete
or install. Kept is not the same as Held. Kept is just what we are
actually going to do in this run, not a persistent flag.

If you choose Mark Upgrades, a bunch of stuff should get marked Install.
You can then tweak manually.

Havoc



Reply to: