|Deletions are marked like this.||Additions are marked like this.|
|Line 106:||Line 106:|
|* i18n everywhere||* i18n everywhere [done]|
Kubuntu package manager tools for Dapper.
Kubuntu Breezy added Adept, the first time KDE has had a first class .deb package manager. We should continue this work in Dapper.
Adept in SVN now creates .po files for translation, we will ship with these. We will also add i18n support to libapt-front for full i18n support in Adept. We will ensure Adept gets into Rosetta to make it easy for translators to use.
Give better feedback (background-busy cursor) while working. Further improve the interface by resolving the responsiveness issues (use threading). Improve startup time. [done]
Show information about required download size and disk space required for installation in statusbar in all Adept applications. Reduce the statusbar width so Adept works better (fits width) on smaller screens. [done]
Adept 2.0 will add the ability to find more detailed package information including a file list, relations to other packages and available information. The interface to do this will minimally impact the current presentation of the package list. The only thing that will be added is a "details" button that appears next to the "install/remove/upgrade/..." button in the expanded package. This details button will replace the package list with a package browser interface (like other modes do). The package browser will show the same info as the expanded package in the list, and additionally a list of package relations (presented in a manner similar to the main package list) tabbed with file list. Other package data will be present that is not available on the short version from package list. [remanining: file list]
The package list will get some modifications, mainly the search interface. The easy tag filter will be removed from the default filter setup and replaced by a new tag filter. This tag filter will be operated mainly by drag and drop and a list of tags that will be placed to the right of the packages and presented in a facet/tag tree. Alternatively, it may be operated by a drop-down menu, if we decide to keep this option based on user feedback. The tag list on the right will have 3 tabs for 3 modes of operation. One will present all available tags, one the most frequent tags in the current view (the default tab) and one the simple tag selection that is currently presented in the easy tag filter. Additionally, the tag filter will be able to specifically exclude tags from search, not only include them. [done]
Moreover, the package list/filters split will be adjusted automatically to exactly fit the height of the filter list. Users can more easily save space by collapsing filters or removing those they don't use. The expanded package info shall have the text of the states colored in the same way the list has. [done]
The Adept interface will be put in for review by and discussion with openusability.
Package context menu will get "reinstall" and "purge" options. [done]
By default the terminal that is used during commit will be hidden and a progressbar will be shown. A button will be present to show the terminal. Eventually, the terminal will be shown automatically if some program is waiting for input there (bar technical difficulties in implementing this). [remaining: input required detection]
Clean up and simplified the filter interface by removing redundant information (like filter names, since the filter function is fairly obvious even without them). [done]
Dependency tracking will be added pending this feature being included in libapt. This will allow for packages to be uninstalled with all the dependencies it brought in automatically uninstalled. In case libapt won't gain this feature, it will be postponed to adept 3.0 since at the time libapt-front will handle it. [dropped for 2.0, rationale: libapt-pkg did not receive the neccessary changes]
A function will be added to summarise changes between cache states. This means, we can provide tooltips and for install/remove/... buttons which will tell the user what changes will be made to the system after that action is selected. Undo and redo functions shall get similar hints. [dropped for 2.0, rationale: the function is fairly inefficient currently and would probably cause visible slowdown of application... this feature will be reconsidered when the internal structure is changed for adept 3.0, which will allow it to be done efficiently]
We will add the ability to set version/release policy (pinning). This is another case where care with the user interface will have to be taken as it is a complex area. Eventually, the detailed package view will get a "preferred release" combo, which will allow to select a release pin per package. More pinning options should be available through "system wide release/version preferences" (a pin editor, mostly) and through a per-package pinning dialog or (most probably) expansion. [maybe-dropped for 2.0]
Work is being completed on an advanced problem resolution algorithm in aptitide. This may be included in libapt. We will ensure this is supported in Adept if this happens. Note: however, the current aptitude algorithm is somewhat problematic. It may be so that the problem will be completely postponed to adept 3.0, together with package status tracking. [dropped for 2.0, rationale: the features were not added to libapt-pkg]
Adept includes an update application to download and install the latest packages. We will create an update notifier to monitor the archive (and sources.list) and bring up a notification when there are updates which will prompt the user to run Adept Updater. Similar to the Ubuntu update-notifier ours should not keep a copy of the dpkg database in memory for longer than necessary.
The notifier should be a small system-tray applet that will display an "OK" (currently a green led) icon when the system is up to date and a "warning" (currently a red triangle with exclamation mark) icon when updates are available. The tooltip will show how many upgradable packages there are.
The applet works to minimize memory and resource use. Apt database is opened only on startup or when it changes. This is done by polling the cache timestamp, so we don't miss when user manually runs an update. We will rely on the daily apt cronjob to update the package list automatically.
When the applet is clicked, adept updater is launched if there are updates available. Otherwise, a dialog box is shown saying there are no updates. On the right click menu, one can run the updater manually to check for updates. The only other actions shall be quit and help.
[remaining: autostart, option to turn off]
The simplified installer will have a wizard-style interface. It should have 2 modes of operation, one where the packages are presented in a way similar to gnome-app-install and one based on debtags. The latter one is experimental though and not a required target for Adept 2.0, comments welcome.
Gnome-app-install interface: the presented package list will reflect Kubuntu menu structure, since it will be generated from the .desktop files shipped by gnome-app-install. It will show just checkboxes and everything else (namely eventual upgrades) will be handled behind the scenes. The current idea is to show a small blurb that says "additional changes need to be done to your system: <details>" where details brings the standard change-review screen of adept. We shall try to minimize risk of damaging the system, eg. by refusing to do installs that remove packages (other than those removed explicitly) without manual review. Note that there will be a separate description pane for the package currently selected, apart from the package list. [remaining: description pane, warning when removing application takes other apps due to single deb -> many .desktop files problem]
Debtags interface: A trimmed down list of packages (only those that have KDE or GTK interface or are part of openoffice/mozilla/<any other important suite>) are presented, with a bunch of useful criteria to search in this list, based on available tags. The presented list may follow the kde menu structure (eg by shipping a tag file that adds info to packages about the menu section they belong to in kde). Icons and eventually other data may be shipped as well. The gnome-app-install database can be exploited too. However, this interface is probably a 3.0 material, yet to be decided. [dropped for 2.0, rationale: time constraints]
If the debtags interface is available, the interface to use will be configurable through the application's menu. The preference will be saved in a configuration file.
An installation wizard for single .deb packages should be created (to be run when user clicks a deb file in konqueror, eg). It will first of all copy the deb into a local repository, which is maintained by libapt-front internally. This way, the package will remain installable in case it is removed by the user. User will be hinted about this fact and Adept will eventually get a utility to manage this mini-repository (like clean it up). Alternatively, the user may select to not keep the copy of the package in the wizard (then, only the Packages file of the mini-repository will be changed to point at the file in its current location... after finishing installation the reference will be removed again).
Then the cache is regenerated (the necessity to do this is a design problem of libapt-pkg... it will be eventually addressed, but only in adept 3.0 and corresponding libapt-front version). A normal apt-style (and adept-style) installation of the package is done then (allowing the user to review the list of changes that will be done to his system, ala adept). Download of the dependencies and dpkg run will be handled likewise.
[dropped for 2.0, rationale: time constraints]
The adept-updater and adept code bases will be streamlined and common code pushed into libept (there's still some redundancy). This code may then be as well reused in the simplified installer. Any new features needed for the new utilities/applications will be carefully considered for inclusion in libapt-front, so everyone can benefit. If time permits.
The plan by APT team is to include new features in libapt-pkg, we will try to take advantage of those as much as possible.
[http://people.freedesktop.org/~mornfall/adept-tags.png screenshot as of 2005-12-12]
December 15th-20th: adept 1.88 (alpha 1)
- the most "intrusive" changes to ui should be done at this point: the detailed package view and package browsing interface, improvements to the filtering ui [filtering ui nearly done, browser nearly done]
- the ui should be fully i18n'd [done modulo few less important strings and the few strings from libapt-front; those shall be fixed in another alpha]
- skeleton of the update notifier should be done [done]
- purge and reinstall options in the UI [done]
- at least basic support for konsole hiding (eventually without "waiting for input" detection) [done]
- interruptible download, cancel button in media swapping dialog [done]
February 12th: adept 1.89 (alpha 2)
- speed and interactivity improvements [done]
- better statusbar [done]
- ability to browse packages in updater [done]
- greatly improved commit progress reporter [done]
- usability fixes [done]
- completion of update notifier [remaining: autostart, turn off autostart]
- most of the simplified installer UI [done]
- add actions on packages to package browser
- i18n everywhere [done]
February 16th-20th: adept 1.90 (beta 1)
- this version should be feature complete
- any serious bugs from alpha 2 get fixed here
- package file list
- version constraints in package browser
- finishing the simplified installer:
- show extended info
- filter/search option
- toggle visibility of unsupported software
March 2nd: adept 1.91 (beta 2)
- fixes for any serious problems that appear in beta 2
- all issues affecting the UI shall be fixed by now
March 12th: adept 1.92 (rc)
- serious issues of beta 2 fixed
- only critical issues will be fixed from now on
March 30th: adept 2.0
- bar need for critical fixes arises, identical to 1.92
-Volker Löchte: Please also have a look at Xandros Networks, it has an excellent GUI
-Petr Rockai: There are few problems with the xandros ui -- too many scrollbars, eventual scalability problem with the treeview. The simple installer will surely take inspiration in this (as well as any other simple installers out there), still trying to improve on the ideas.
-Duffman25: One of the features I miss in adept from synaptics is the hability to find orphan packages with filters & to see the configurations files left over from packages uninstalled but not purged. Is this possible with adept & I didn't find it or those features aren't implemented? Thanxs