[Aptitude-devel] Plans for aptitude 0.5.0 - 0.6.0.
dburrows at debian.org
Sat Sep 6 03:15:48 UTC 2008
I just wanted to post what my general plans are for the aptitude 0.5.0
line and its development into 0.6.0. For those of you who haven't been
around as long, aptitude uses old-Linux-style version numbering; 0.5.0
will be a series of unstable releases along the road to 0.6.0. For
comparison, there have been two previous development series: 0.1.0,
circa 2001, was the rewrite to use signals, slots, and something
resembling a real widget system; 0.3.0, circa 2005, was a rewrite to
use Unicode everywhere and threading in a lot of places.
Probably the main person who will be interested in this email is
Arthur, but of course anyone else who wants to chime in can. :-)
So, here's what I see.
0.5.0 -- released mid-October to experimental
... -- some number of interim releases
0.6.0 -- released around Christmas (this may be too optimistic;
perhaps more like February-March?)
In each release, I'd like to try to maintain three invariants:
* All the widgets the user can see will work.
* No major known crashing bugs.
* All documentation is up-to-date (except that we might not write
any documentation for the GTK+ frontend until sometime after 0.5.0).
The basic idea is that 0.5.0 should have all the core functionality
we want; the development on the way to 0.6.0 will consist of improving
UI and adding less critical features. Also fixing bugs, should any
arise. Estimated times are the time I think it'll take to design and
implement a basically working version of the feature without any major
bugs; one day = 8 hours.
The following features are the ones that I think are aimed at
0.5.0 vs 0.6.0. "For 0.5.0" means I think it absolutely should be
in the first GTK+ release. "For 0.5.0, if possible" means I'd like
to get it into the first GTK+ release, but I think we could defer it
if it turns out to be too much difficulty. I used this for entries
that I'm not quite sure how to implement (so they may need some
experimentation). "For 0.6.0" means I think it should be in the first
stable release of the GTK+ frontend. "For 0.6.0 or later" means that
I'd like to get it into the first GTK+ release, but we could also
implement it later (if, again, it turns out to be too much trouble).
Let me know what I forgot.
Major TODOs for 0.6.0:
* Show dpkg interaction inside the program instead of in the
+ For 0.5.0: pop up dpkg in a new tab. Estimated hack time: 4-8
hours; we just need to integrate support for libvte.
+ For 0.6.0: display a progress bar showing what dpkg is
up to in a notification bar, with a button to open the dpkg
output. Estimated hack time: unknown, probably <8 hours.
* Xapian support in search patterns.
+ I've been working on an overhaul of the search code to support
this and the other search-related feature below.
+ For 0.5.0: support Xapian-indexed queries. Bare strings should
produce full-text queries against any and all relevant
information sources (this will probably take some tweaking to
get "just right"; e.g., do we search tags?). Estimated hack
time: 2-3 days.
+ For 0.6.0 or later: support highlighting matched terms,
incremental search, sorting by relevance, and perhaps
interactively narrowing the search. Estimated hack time: 4-5
Highlighting matched terms will probably be especially tricky,
or at least will take a lot of typing.
* Support for interactively editing search patterns.
+ For 0.5.0, if possible: write a UI to let the user build complex
queries. Some sort of an "Edit..." button next to "Find" that
causes the editor to appear; the editor will change the search
that's being used and replace the text in the sesarch box.
With the ground work I've done over the last few days, this is
just a matter of converting the aptitude::matching::pattern
class to some sort of live editing widgets (and back). The
harder question is figuring out what the end goal is.
I'm not sure what the UI should be. For displaying the editor,
a tab doesn't feel right; maybe a dialog or a fold-out region
in the package list? For the editor itself, I don't know what
works for people. Email clients and Web browsers that I've
used just display rows of widgets, one row per match term, but
I think this might not work for expressions with nesting, etc.
Another option would be some sort of tree view.
Once we decide on a UI, I estimate that this will take 1-2 days
to implement. If we end up throwing the first one out, it'll
* Upgrade planner.
+ For 0.5.0, if possible: design and implement a tab that brings
together the tools that are useful in an upgrade: a list of
upgraded packages, a dependency resolver, and changelog viewing.
(what else / how to put them together?)
+ For 0.5.0: The "dashboard" tab should contain some useful
content. Either that, or we should just hide it. Estimated
hack time: 1-2 hours.
+ For 0.6.0: We could use the dashboard to give the user quick
buttons to access common stuff (a text box to search for packages,
a button to start an upgrade), and perhaps a list of pending
upgrades (with some text from the changelog of each one).
Estimated hack time: 4-8 hours.
* Dependency resolver.
+ Already implemented: basic support for displaying solutions and
moving between them.
+ For 0.5.0: we should at least support the "accept" and "reject"
actions. My preferred UI is a pair of thumbs-up/thumbs-down
icons in package rows, but I guess I could settle for check
boxes. Estimated hack time: 2 days, mostly spent trying to
wrestle GtkListView into submission.
+ For 0.6.0 or later: I think there are probably more ideas to
explore, but I haven't come up with very many clever ones. For
instance, displaying a list of the solutions the user has
generated and visually indicating which ones aren't allowed by
their current constraints. Estimated hack time: unknown.
* Package list.
+ For 0.5.0: there should be an easy way for users to display
more or fewer columns (for instance, right-clicking on row
headers?) This of course means we'll have to generate more
columns. ;-) Estimated hack time: 4 hours.
+ For 0.6.0: we should investigate using a custom TreeModel so we
don't have to instantiate the whole list at once. For larger
result sets, I expect this to be a major savings. Estimated
hack time: 1-2 days (mostly design work).
+ For 0.6.0: get some better icons. The stock ones just don't
cut it for package management. (IMO) What does an envelope
mean? What about a rewind button? Estimated hack time:
unknown, find a graphic artist or some free-as-in-speech
+ For 0.6.0 or later: Support displaying popularity and sorting
by it. Maybe we could use something like network strength
indicators? i.e., up to 4 bars of increasing height. Estimated
hack time: 4 hours.
* Package information.
+ Already implemented: support for displaying changelogs.
+ For 0.5.0: changelog downloads should happen in the background.
+ For 0.5.0: the "files", "popcon", and "tags" tabs need to either
be implemented or to be hidden. Estimated hack time: <1hr for
"tags", 2hrs for "popcon", and 2 days for "files" (or about 5
seconds each to hide them).
+ For 0.5.0 or later: expose the "why" information in the info tab.
+ For 0.6.0: they should really all work. Slower tabs (like
changelog and files) should be loaded in the background.
+ For 0.6.0 or later: use an html renderer for displaying
descriptions and other info? The TextView is annoying to
work with; a real HTML renderer would get us goodies like better
rendering of lists and indented text.
More information about the Aptitude-devel