[Aptitude-devel] aptitude-qt mockups comments

Wed Jun 9 19:29:35 UTC 2010

2010/6/7 Daniel Burrows <dburrows at google.com>:
> 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.
>

Great. Will be done.

>>> 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 was afraid that gui will be too much cluttered.  categories list is
on the left in my design, so I think that package information on the
right is not good idea (Probably there will be not enough horizontal
space) . Due to that, there is only one possible place for this pane:
under packages list. The problem is that this pane should always be
visible in that situation, so there will less vertical space.
Furthermore, I had a look on KPackageKit and Adept GUIs and it looked
quite usable ;)

>>> 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.
>

That was my first plan. Debtags came later, but I think it will be
nice to join this two ideas.

>> 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).
>

No problem. XML was only a proposition, because I have experience with
parsing. The format should be suitable for both guis. Maybe it will be
good to write this parser and filter as generic classes, so the code
could be simply shared.

>  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.
>

OK.

>>> 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.
>

It could be a problem. Scrollbar will not look good. When designing it
I was thinking about 3-4 different versions. I will have a look on
this.

>>> 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.
>

OK.

>> 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.
>

Thanks for the clarification. With an arrow on the left there is a
some free space on the right, so this could be done in some way.

>  Daniel
>

Tomorrow I will think about this more, and prepare updated mockups.

-- 
Regards
Piotr Galiszewski