[Aptitude-devel] Towards better upgrading.

[Daniel Burrows]

On Tue, Feb 03, 2009 at 02:30:28PM +0100, Obey Arthur Liu <arthur at milliways.fr> was heard to say:
> The introduction of the Upgrade button was to create a more
> workflow-oriented and less feature-oriented interaction possibility.
> The problem is that we chose the "notification balloon" metaphor: this
> metaphor is usually used to point out informational and optional
> information. Many users pointed out that they don't know what to do next
> because they didn't notice that the notifications were actually (nearly)
> mandatory prompts.

  Yeah, that's also on my radar.  A lot of stuff shows up as
notifications, and so the notification area just gets cluttered.

> Clearly, the usual path is :
> 1) Show upgradable packages
> 2) Display resolver
> 3) Show a preview of the changeset
> 4) Show the download process
> 5) Show the dpkg run

  (2) should not be in the usual path, IMO -- I hardly ever use anything
but safe-upgrade from the command-line any more, and anecdotally I've
heard the same thing from others.

> We need:
> 1) Get the executed steps out of the way
> 2) Highlight the next step
>
> So, what do you think?
> 
> I like the tab highlighting idea because it can be reused to, for
> example, highlight infotabs which packages changed state (say, to broken).

  Hm, I don't think tab highlighting will solve this problem,
especially if we use it to mean other things too.  If anything, I think
a flashing tab is more cryptic than a popup message.

  Another option: what if "important" / "task-oriented" notifications
appeared at the top instead of at the bottom, and flashed?  That might
seem like a minor change, but I think that we do tend to notice stuff
at the top of the display more than stuff at the bottom, probably due
to cultural conditioning.

  Also: we could add a visual cue that a popup / notification / tab had
to do with a particular task (e.g., carry the "upgrade" icon along in
each step; I'd put it on the left side of a notification or in a tab
header, maybe along with the text "Upgrade:").


  I think that if we really want to be sure that they see the message
and are forced to click on it, we'll need a pop-up dialog, as annoying
as I find them.  (maybe I can add an option to convert them to
notifications, like the one the curses UI has to convert popups to
minibuffer prompts)  I'd like to avoid that if possible, but I think
a popup will be necessary if you want to cater to users who are confused
by plain text telling them what to do next. ;-)

> > >   I'd like to smooth this out and make it more along the lines of
> > > "safe-upgrade".  Here's what I imagine:
> > >
> > >   (a) start aptitude.
> > >   (b) push the upgrade button.
> > >   (b.1)
> > >     if there are broken dependencies, as many packages as possible are
> > >     marked for upgrade.  A notification appears saying something to the
> > >     effect of "some upgrades couldn't be installed without taking
> > >     'risky' actions.  Fix manually?"  (or "no upgrades could be ..."
> > >     as appropriate)
> 
> I'd describe supplementary upgrades as "additional actions" and actual
> downgrades as "risky actions", but fine.

  I said "to the effect of", meaning that is the information that should
be conveyed but not necessarily the wording :-).  But supplementary
upgrades, unless they're from a non-default repository, *are* included
by the safe-upgrade algorithm, as are supplementary installs.  Only
non-default repositories and removals are blocked out, and I'd describe
both as risky.

> > >   I'm looking at whether it's possible to equip the resolver with the
> > > ability to reason about "hypotheticals", so that it can run in the
> > > background without altering the current package states.  I haven't
> > > decided whether this is actually desirable in this case (with
> > > upgrades), but it's not too hard a hack and may be useful in other
> > > circumstances anyway.
> 
> And give us a 3D tree with keeps/upgrades/installs as x/y/z-axis ?  :)

  Eek.

  No, but I do want to put in support for approvals / rejections -- the
main reason I haven't is that the way I envision it happening requires a
nontrivial custom cell renderer.

  Daniel