Note: This bug was moved here from the redhat bugzilla at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=20063

Start gnorpm, Install -> Add.

Here are several nit-nots against the Add Packages screen:

1) Previously selected values for directory should persist.

2) Screen is confusing, as mentioning a directory causes all packages below
that directory to be added, while selecting a file displays info but does
not
select the package. I'd suggest calling the screen something like "Get
Packages From",
and dumping the per-file info display. 

3) The screen needs some way to adjust the "what to Install filter"
currently located at
 the top of the parent page. And, while I'm here, the default selection
should be
"Only newer packages" as that's far more sane than the current "All but
installed".

Here are nit-nots for Install/Upgrade screen(s):

1) Displaying "Dependency problems" as a pop-up is just stupid. You either
select
Yes (with dumb warning about unstable systems), or you select "No" in which
case
the info you need to adjust the selected package list vanishes. At a
minimum, the
ability to deselect problem packages from a button click should provide a
saner
choice than the currently available Yes/No. (Note: deselecting isn't
perfect as it
deselects only nearest neighbor dependencies, deselecting all packages that
depend on the deselected set is even better yet.)

2) Displaying error messages from stderr during package install with single
accept
button is equally dumb. So what am I gonna do, reboot to stop the install?
Far better
interface would be to run scrolled stderr ouput during  running of
transaction set, with
appropriate markers so that the package generating the error can be easily
ascertained.

3) Displaying Information pop-up as "Update of N packages failed" OK? is
simply
annoying. Even worse, if an upgrade were to actually complete successfully
without
hitting one of the stoppers above, one has to infer from the non-existence
of
a pop-up that the Install/Upgrade succeeded. How about adding a status
field to the Install
screen that is updated with the status of the previous operation?

4) Then there is the pop-up nesting problem, as parent screen(s) appear
reluctant to accept
events while a child is active. Simplifying the cascade in the ways
mentioned above would permit the parent Install screen to continue
accepting events without the annoyance of
having to find and eliminate Yet Another Pop-Up, although there may even be
more
intelligent ways of handling the problem within GTK itself. Dunno GTK.

5) The "Installation problems" pop up is far too small for most of the
rather long-winded problems delivered back from a failed transaction set
run, and it's ridiculous to have to scroll
several screenfulls right just to find out what happened.

Gack, there's more, but I'll open another bug ...