Re: gnome-apt screenshot, more questions
On Thu, 26 Nov 1998, Lalo Martins wrote:
>
> Ok, my comments:
>
> 1: I didn't like the checkboxes:
>
> 1a: There should be "purge" too.
>
Easy to add more checkboxes, but I don't know how to do this with Apt.
There is no MarkPurge() function with the MarkDelete, MarkInstall,
MarkKeep functions.
> 1b: They're mutually exclusive, so at the very least they
> should be radio buttons.
>
Well, they are radio buttons in effect; i.e. if you click install, then
keep gets unmarked. I could draw them like radio buttons, I just thought
the check button look was nicer. (This is a purely cosmetic issue, so
let's not worry about it. All cosmetics can eventually be changed or made
configurable.)
> 1c: You should also display the current status, and what was
> the previously selected action, a la dselect
>
Oops, I forgot the status column, yes. I have skeleton code but it's not
filled in.
I don't know how to find out the previous state; perhaps this should not
be in the tree view, since we seem to have too many columns. It can go in
the info panes? I guess it may as well be an optional column too.
I need to know how to find out what it was though.
> 1d: Why change "hold" for "keep"? Of course "keep" sounds
> better, but why introduce a UI incompatibility?
>
I copied the old Apt screenshot (Jason gave the rationale just now I
guess). However we have no Hold button; should we have a Hold check box?
> 1e: Visually, I think the action selection would look better
> using that popup-selection widget (don't know the name of the
> corresponding GTK widget, but I mean the one that corresponds
> to a non-multiple <select> HTML tag)
>
GtkOptionMenu?
The problem is that the tree view can't have widgets in it; they are too
slow. It is all drawn manually to a pixmap then copied to the screen in a
single operation. Menus would be sort of busy anyway, IMO. Check boxes
are clean. We can also reduce the space they take up by using
abbreviations for the column titles (DKI, not Del Keep Inst).
> 2: I find the current version of the tree hard to swallow; if I
> want to imagine myself using gnome-apt, I have to mentally add
> the "+/-" buttons :-) Of course the final version will have
> these, so ignore this comment...
>
Yeah, I am just too lazy to draw them. We can do that later. I want 1)
working program then 2) looks nice.
> 3: bash depends on libc5, ncurses3.0 and libreadline2;
> libreadline2 depends on libc5 and ncurses3.0. I think that, by
> default, libc5 and ncurses3.0 shouldn't be listed under
> libreadline2, since the purpose of the relationship listing is
> to know what packages you would have to install, and duplicates
> make little or no sense in this context.
>
See Jason's comment; I'm not sure how to avoid this anyway (for each
dependency, go back up the tree looking for it?).
> 4: I definitely don't like the package info (gdeb or not) on the
> top. I'd like it either on the bottom or to the left. But then
> again, this is GNOME; I think the best thing we could do is
> leave these options to the user - give as options top, bottom,
> left, right (yuck), and separate top-level window as Wichert
> said.
>
This is pretty trivial, but I'm not going to do it until things are
working better.
> 5: I maintain thatg deb would be good to use (with the notebook
> - more on it later). The "Relationships" page is good to have
> even when the dependencies are already in the tree, because
> whatever its interface will be, it will be clearer (more
> newbie-friendly) than the tree. Of course, once someone got the
> knack of what the tree means, it makes things faster (so it's
> more power-user-friendly). So we should keep both.
>
I like the relationships page, I'm just not sure where to put it.
> (x) Hold - leave package in its current state
> ( ) Install - install or upgrade the package
> ( ) Remove - uninstall the package, leaving its configuration behind
> ( ) Purge - uninstall the package, deleting its configuration
>
I like this, I don't want to make it a separate thing though, just put it
in with the other status info. Since this is both info and a UI at the
same time.
> ALL OF THIS SHOULD BE CONFIGURABLE OUT.
>
> Have one option somewhere to omit the action buttons, one to
> omit the name-and-short-description box,
> and one to display the
> notebook in some other format.
>
Of course. I know I keep saying this, but I do want to wait until the code
is nearer to done; because once you finish it's easy to add conditionals
around any of the UI calls to make them configurable. Similarly it's easy
to change gtk_paint_checkbox to gtk_paint_radio whenever we feel like it.
> * Get rid of the tabs and display only one page - Info by
> default; then if you want to see Relationships or Special you
> can choose it in some menu (probably Package)
>
> * Stuck everything in a VBox or HBox - ugly, but some people
> would definitely want it
>
Once I figure out the contents of the Info/Description panes, I can figure
out how to put them in a notebook or not... I don't know exactly what info
we want here yet or how much will fit...
Havoc
Reply to: