[Aptitude-devel] Complex search query creation widget

[Daniel Burrows]

On Thu, Dec 25, 2008 at 03:06:08PM +0100, Obey Arthur Liu <arthur at milliways.fr> was heard to say:
> I've been thinking about adding some GUI to expose the powerful search
> query syntax of aptitude. It's a shame that many don't use it.
> Currently, there's mainly a Entry for the query and a Button to initiate
> search. There's also a ComboBox to limit the query according to the
> installed/not installed/whatever status of the package.
> 
> I'm joining a changeset that adds some checkboxes for "broken",
> "configured"... and puts everything except the Entry and Button into an
> expander.

  I don't think that a search like this is especially useful, since it
only supports a few pre-chosen searches and will very quickly become
cluttered -- I'd rather introduce a search term builder like you find in
a lot of mail clients.  I'm thinking it would be a dialog or a separate
tab (this would also mean we could use it to build new filters in the
dropdown menu).  The whole thing would be popped up by an "Edit..."
button next to Find.

  Perhaps something like this (sorry about the bad ASCII-art):

+------------------------------------------+------------------------------+
|             Search Term Entry            | Find:                        |
+------------------------------------------+                              |
|Tree view of search?                      | +--------------------------+ |
|                                          | | Broken Packages          | |
|                                          | | Config-Files             | |
|                                          | | Installed                | |
|                                          | |>Name<                    | |
|                                          | | Obsolete                 | |
|                                          | +--------------------------+ |
|                                          |                              |
|                                          | Packages whose name          |
|                                          | matches the given string.    |
|                                          |                              |
|                                          | [ ] Use regular expressions. |
|    [Add Term]  [Add List of Terms ]      | Name matches: [xyzzy]        |
+------------------------------------------+------------------------------+
|                         [Copy to clipboard]  [Save and close]  [Cancel] |
+-------------------------------------------------------------------------+

  The top-left pane is a text entry that displays the current search
expression (I'm not sure if the user should be able to edit it manually,
but it will update whenever the search is edited).  The left center pane
displays some sort of rendering of the current search with a way to pick
a particular term to edit -- I'm thinking of a tree-view, but that might
be too hard to read.  The right pane edits whichever term is picked, with
the widgets below the pane updating according to which type of term is
chosen.

  One problem I see: some terms have sub-terms.  If the user temporarily
switches to another term, we (probably) don't want to clobber the
sub-term.  I can see two solutions: either remember the last sub-term
of each term and automatically reinstate it when a sub-term comes back,
or have the user specify up-front that a term has a sub-term, and only
let them switch to other term types that have sub-terms.  I suspect the
first option would be a bit more friendly, and I think it's probably OK
if discarded sub-terms are lost when the dialog is closed.  But the UI
above shows the second option -- the user can choose to add a new
non-list term or a new list term.  That doesn't deal with terms that
have a fixed number of sub-terms, though (such as ?widen or ?narrow).

  Another option that you see from time to time would be to build a
collection of rows, one per term, with dropdown boxes to choose the type
of match each term makes, and the ability to insert parens and change
connectives.  That won't scale as well, but might be more intuitive
for small search expressions (and arguably anyone building a large
search is capable of familiarizing themselves with the search language).



  I'd also like to add a "build-search" command-line action that just
pops up the search dialog rather than running the package manager;
instead of "save and close" we would have "copy to clipboard and close",
maybe also with options to write to standard output and close, load a
given expression into the editor on startup, etc.

  Eventually the curses UI should get an equivalent editor, but it's a
lot easier to hash this sort of thing out with GTK+, so let's start
there.

  Daniel