[Soc-coordination] Applying for improving Aptitude packages query utilities

[Daniel Burrows]

On Tue, Mar 24, 2009 at 12:15:16PM +0800, sha liu <sandyleo26 at gmail.com> was heard to say:
> I think i got what you mean. However, considering the fact that so many web
> browers and text editors today can highlight the search word, isn't there
> some available library or something like xapian with which one can do this
> job easily?please correct me directly if i'm wrong about that, because i
> didn't do any useful research on that. i'm just curious about it.

  It's true that highlighting is relatively straightforward (depending
on how you do it exactly), but there are a few challenges around it,
like figuring out how to communicate information about highlights from
the backend to the frontend.  Also, currently Xapian doesn't provide the
match location, although I suspect that this is mainly because the
database isn't built with that information.  You could just search for
literal occurrences of the string, but if there any sort of inexact
match is possible (match up to 1 edit distance, match with
transpositions, stemming, etc) then you need to be able to find the same
inexact match in the description.  And you need to deal gracefully with
a situation where the search database isn't up to date.  Do you do a
second-pass filter where you throw out things that don't match, and do
you haven't inexact matches in that pass?  etc.

  The main reason I grouped them like I did is that highlighting and ranking
results both require a lot of work inside the search backend and relatively
little work in the frontend, whereas writing an editor dialog requires a lot of
UI work and very little work with the backend (the optional work writing new
query terms will touch the backend, but not the part that uses Xapian).  So
people who take those tasks can focus on one part of the program or the other.

> > At a first glance, I'm not very enthusiastic about the idea of trying
> > to assign icons based on package "categories"; it seems like it would be
> > very hard to design icons that visually represent categories, and it
> > would be hard for the user to remember them.  I'd rather just add
> > sections to the list as text (and now that we have more sections, they
> > might be halfway useful again).
> 
> 
> yeah, the icon selection is very tricky for me too. However, I still think
> many same color and same shape icons stacking  together is a little
> confusing , especially for the colorblind people. But the brief description
> showed when hovering mouse over the button could alleviate the pain, though.

  I think the actual icons are not the best, but we wanted icons from
the GTK+ theme (so they adjust appropriately when the user changes
theme).  Also, we didn't want to have to draw. :-)

  I don't get your comment about same color and same shape icons?  The
different icons have different colors and shapes -- if things have the
same icon, of course it's the same color and shape.

> Since aptitude can *define* the conflictions and *provide* suggestions now,
> maybe we can brief these two kinds of information into messages. Of course
> the key part of the message are only the package names and versions. And
> with this kind of message, user can easily google it automatically or
> just copy-paste and google them manually. At least, user will not have the
> trouble to input the package name into google themselves anymore.(some of
> the packages names are really hard to remember at your first glance).

  So, here's an example.  Tell me if it's what you're thinking about.

  When aptitude says, at the conflict resolution screen, "I want to
remove gnucash", the user could click on that message and see (in
another pane), something like:

    * gnucash depends on libgnomeprint2.2-0
    * libgnomeprint2.2-0 depends on libgnomeprint2.2-data (= 2.18.5-1)
    * libgnomeprint2.2-data is being upgraded to version 2.18.5-2

  Daniel