[Aptitude-devel] aptitude-qt mockups comments

[Daniel Burrows]

On Sun, Jun 6, 2010 at 1:46 AM, Piotr Galiszewski <piotr at galiszewski.pl> wrote:
>> I noticed that you divide updates according to their priority. This is a nice idea, but unfortunately the priority is only stored in the changelog. The changelog has to be fetched and < parsed separately from the package lists, it might not be available, and it can take a long time to fetch all the changelogs for a large update.
>>
>
> I have forgotten about this. This change the situation and with
> reference to your later comment about useless  of this information for
> users, i will abandon this idea. Maybe it will be better to
> distinguish security updates from http://secutiy.debian.org?

  Yes, distinguishing security updates is a good idea.

>> Is that pop-up with package information just a tooltip? I think it would be good to avoid having it be too easy to dismiss. e.g., it could appear when the user clicks on the package and disappear when they click again.
>>
>
> It is not pop-up. It is integral part of the list (maybe child in tree
> view) which show on single click, and disappear on next click (exactly
> like you described - it looks like my English is not good enough to
> describe things in clear manner ;) ). There could be more than one
> package information show at the same time.

  Ok.  I'm curious, is there any particular reason you decided not to
go with a multi-paned display?

>> I like the idea of filters down the left-hand side (it's one of my TODOs for the GTK+ code, actually, and it would be nice if you can design this so that the two UIs can easily share the list of filters).
>
> I discussed this list with Sune on last Sunday, and we agreed that
> sections are not good choice to be shown as categories.

  I agree with this.

> We decided
> that debtags will be better. By default, there will be shown some
> ?most popular? tags as a categories: eg. kde, gnome (abbreviation from
> suite::kde/gnome), admin, audio, im etc. "Manage Filters" will show a
> dialog, where for example it will be possible to select tags (group of
> tags) to show as categories. Other option should also be available.

  My assumption was that "manage filters" would eventually let you
build any search over the package list.

> As for sharing maybe saving list in xml will be good solution?

  The one problem there is that XML is kind of a pain to generate and parse.
Maybe something more lightweight could be used -- e.g., a simple rfc822-style
tag-based approach (apt has a parser for tag files).

  It would also be good if we could sponge up filter definitions from
/etc/apt/apt.conf.d, so that system administrators or packages could
easily extend the hardcoded list.

>> I have some questions about the version list.
>>
>> What will you do if there are more than two versions? Just put up a scrollbar?
>>
>
> No. There will be new row for each version without scrollbar.

  Make sure the layout is reasonable up to, say, six or seven
available versions.
Apparently some people like to have that many archives in sources.list.

>> I'm not sure about using a whole column for "current" and "show details". Instead maybe you could make the version number a link that selects that version? That column would be handy for displaying the release that a package comes from. It would also be nice to flag the candidate version, although I'm not sure how to find a balance between cluttering up the UI ("default" is probably too much text) and having an indicator that's too cryptic (the meaning of "*" isn't obvious).
>
> I thought about it, but I was not sure, if it will be intuitive for
> users.

  That's a point.  It seems fairly obvious to me, but what do I know? :)

> As for indicator what do you thin about an arrow on the left
> side presenting current version?

  I think that makes sense.  I was also thinking about changing the
background, but if there are only two versions available it might not
be clear which one is chosen.  An arrow avoids that.

> As "candidate version" you mean a
> newer package version than currently installed?

  The candidate version is the version that apt "thinks" should be
installed.  Normally this will be no older than the installed version
but it's not necessarily the newest version (depending on things
like pin priorities).  In fact, it's even possible for the candidate
version to be a downgrade, although that's an unusual situation.

  When you run "apt-get install X", the version of X that gets
installed is the candidate version.  When you ask apt to upgrade,
it upgrades every package to its candidate version.

  One of the frequent questions that users have is which version of
a package is going to be installed and why it got picked instead of
something else.  I'd like to make this more transparent in the UIs if
possible.

  I particularly want to flag the candidate version because it's the
version that's the "default" version for the user's system.  Other
versions are likely from other releases of Debian, and we should
make that clear so they don't get installed by accident.

  Daniel