Permalink
Fetching contributors…
Cannot retrieve contributors at this time
358 lines (280 sloc) 12.6 KB
-------
Purpose
-------
pacman-curses is a curses frontend to libalpm. It is intended to provide a
"graphical", convenient, easy to use alternative to pacman for simple routine
tasks such as browsing, searching, and installing / removing packages. It is
NOT intended for any more advanced tasks, which are better left to pacman
itself. Seeing this as a side by side companion to pacman is probably the
correct point of view.
The interface should be very simple, friendly and intuitive, similar to mc and
mocp. Likewise, the code itself should be very simple - this is a one man
project and like this it has the best chance of staying clean and actually
getting finished.
------------------
Technical Overview
------------------
pacman-curses is written in C++ using ncurses and libalpm. The interface will
consist of two panes, very similar to mc and mocp.
Info View:
+Pkg List--------------------+Pkg Info-----------------------------------------+
|[--] 3ddesktop |name: 3ddesktop |
|[--] 6tunnel |version: 0.2.9-3 |
|[--] 9base |url: http://desk3d.sourceforge.net |
|[--] a2ps |repo: extra |
|[D-] a52dec |packager: Eric Belanger <eric@archlinux.org> |
|[D-] aalib |builddate: Thu Mar 26 03:13:36 2009 |
|[E-] abcde |install reason: not installed |
|[--] abiword |desc: a 3d virtual desktop switcher (opengl/mesa)|
|[--] abiword-plugins | |
|[--] abook | |
|[E-] abs | |
|[--] abuse | |
|[--] acct | |
+-2498 Pkgs (400 installed)--+-------------------------------------------------+
Queue View:
+Pkg List--------------------+Pkg Queue----------------------------------------+
|[--] 3ddesktop |S pkg1 |
|[--] 6tunnel |R pkg2 |
|[--] 9base | |
|[--] a2ps | |
|[D-] a52dec | |
|[D-] aalib | |
|[E-] abcde | |
|[--] abiword | |
|[--] abiword-plugins | |
|[--] abook | |
|[E-] abs | |
|[--] abuse | |
|[--] acct | |
+-2498 Pkgs (400 installed)--+-10 R 20 I 200.3 MB DL +500 MB/-200 MB INST------+
Configuration is read from pacman.conf.
The left pane displays an (optionally filtered) package list. Each package is
displayed only once, regardless if it appears in more than one repository.
Earlier repositories win, which means testing/make would be displayed while
core/make is hidden.
It can be navigated by record, by page, and by jumping to the beginning / end
of the list.
The list can be filtered by fields (like name, description, ...) and other
criteria such as install status.
The list uses colors. These can display a packages installation status (not
installed / explicit / as dep) and more.
It also shows a summary of appropriate details.
The right pane has 2 modes, Info and Queue.
In info mode, the right pane simply displays package infos. The pane cannot be
focused or scrolled. It is updated every time the focused package in the list
pane changes.
In queue mode, the right pane displays all packages queued for an operation
(remove / install) as well as the operation and other details
(download size, installed size, ...). This list is also color coded. The queue
displays only packages added by the user. Implicit dependencies are either 1)
NOT displayed or 2) displayed but greyed out and cannot be directly modified by
the user.
--------
Commands
--------
Global
------
Filter Pkg List:
Filters the displayed packages by a filter phrase. Filtering can be specific
to a package field, eg name/repo/group/provides. Field selection is handled
in the syntax of the filter phrase. Default is name/desc/provides/groups.
Sort Pkg List:
Colorcode Pkg List:
Similar to Filter Pkg List
Clear Pkg List Filter:
Reverts to displaying all available packages.
Quit:
Exit the application.
Begin Transaction:
Begin processing the queue. This is handled outside of ncurses mode,
similarly to Sync DBs. Pacman callbacks display progress bars and any other
messages. The queue pane is only cleared if the operation completes
successfully. Aborting the operation (Ctrl C) is handled like an error.
Switch Right Pane Mode:
Toggles between Info and Queue modes. Focus is restored to the left pane.
Switch Focused Pane:
Switch focus between list and queue pane. If info pane is currently
displayed, automatically switch to queue mode. The caption of the selected
pane is highlighted.
Help:
Display a popup window listing all commands.
List Pane
---------
Add Pkg to Queue:
Adds the selected pkg(s) to the queue. If Pkg is currently installed, the
queued operation is 'Remove', otherwise it is 'Install'. If pkg is already
in queue, does nothing. Does NOT remove the pkg from list pane.
Remove Pkg from Queue:
Removes the selected pkg(s) from the queue. If pkg is not in queue, does
nothing.
Multiselect Toggle:
The user is able to select a collection of packages by using the multiselect
command. Toggles the selected state of a Pkg.
Multiselect Regexp:
Similar to Filter Pkg List
Queue Pane
----------
Multiselect:
The user is able to select a collection of packages by using the multiselect
command. Toggles the selected state of a Pkg.
Remove Pkg from Queue:
Removes the selected pkg(s) from the queue.
------------------
Details: List Pane
------------------
+-Pkg List (/n:searchphrs)---+ <-- Header, search phrase
|[--] 3ddesktop | <-- actual package list
...
|[--] abiword-plugins |
|[--] abook |
|[E-] abs |
|[--] abuse |
+-2498 Pkgs (400 installed)--+ <-- status bar
The list pane owns a vector of pointers to Package objects. All of these are
displayed in the pane. When the list is filtered, the vector is altered to only
contain the corresponding packages.
The Package class is a thin wrapper around alpm's pkg functions. Additionally,
it contains a few fields we need internally, like a pkg's selection status, its
queued operation, etc.
In details, display:
Install status
Availability of upgrades
Orphan status
Foreign status
Queue status
Display details as columns? Or only a list of applicable chars (EU == Explicit,
Upgrade Avail). Columns are easier to read but a list of chars is shorter.
Columns might not make sense for fields that are rarely filled (orphan, update
avail).
Color code by:
Repos? (how to handle many user repos?)
Install status?
In the status bar, display:
Nr of pkgs in filtered list
Nr of installed pkgs in filtered list
-------------------
Details: Info Pane
-------------------
The info pane indicates which attributes are used to sort / color code.
-------------------
Details: Queue Pane
-------------------
+-Pkg Queue---------------------------------------+
|S abook |
|R abuse |
...
| |
+-10 R 20 I 200.3 MB DL +500 MB/-200 MB INST------+
Color code by:
Queued operation
Explicit/implicit (dep) target (if we choose to display these in queue)
In the status bar, display:
Nr of queued packages to 1) remove 2) install
Download size
Installed size (delta?)
-------------
Details: Misc
-------------
Text Entry Area
---------------
A text entry area is needed for filtering. The simplest way to handle this that
I can think of right now is to overlay the bottom row with an input area when
needed and hide it when not needed.
Color Coding
------------
Only applies to package list.
Color coding is done using the similar syntax as filtering (except it uses a
different operator).Allows color coding anything that is listed in the info
pane (Name/Desc/Repo/Install Status/...). Of course this doesn't make sense for
things like Name, but its very consistent with filtering. We define a sequence
of colors, get the distinct values of the defined field, and apply the colors
according to that. If there are more values than defined colors, cycle around
and start from the first color. Applies only to contents of currently filtered
list. Values are sorted alphabetically, so assigned colors are always the same
for the same set of values.
Syntax could be:
12
.[ndg...]
1 is the command to start color code mode
2 is a single field descriptor
Default is install status.
Multiselect
-----------
Multi select can either be done manually by using the Toggle Multiselect
command, or with a syntax identical to filtering.
Syntax could be:
,[ndg...:]regexp
This doesn't toggle all selected states; it toggles the selection state of the
first package and applies that state to all others. Applies only to the current
contents of the filtered pkg list.
Groups
------
For simplicity, pacman-curses does not have foldable lists (treelists) or
navigateable lists. Installation/removal of groups is handled by filtering the
list by a group name and then adding the desired packages.
Sorting
-------
Handled using syntax similar to filtering.
m[ndg]
Sorting is always ascending. Secondary sort field is always Name
Default is Name.
Filtering
---------
Filtering must be able to handle
1) filtering by a specific field (name/desc/...)
2) filtering using either 'contains' or 'exact' matching (?)
3) regexp matching (?)
4) combined filters (name = .. AND repo = ..) (?)
Realistically, 1) and 3) sounds like the simplest choice. Syntax:
12 3
/[ndg...:]regexp
1 is the command to start filter mode
2 is one or more field descriptors followed by ':' (optional)
3 is the actual search regexp
Besides text matching filters, it should be possible to filter by things like:
Install status: Not installed/Explicit/Dep
Orphan status: Orphan/Not Orphan
Foreign status: Foreign/Not Foreign
Queue status: Queued/Not Queued
Selection status: Selected/Not Selected
With these nontext filters, it would also make sense to allow chaining filters.
Make all filters apply using AND logic, and only clear them when the user
specifically uses the 'clear filters' command. This can be implemented by
filtering the same list over and over again.
We might be able to handle this using standard text filters by listing this
stuff in the info pane in an easily filterable way. Something like:
Orphan: y (/n)
Foreign: y (/n)
...
Clearing a filter does NOT reset the colors and selection states.
System Update
-------------
A system update '-Su' should be mostly equivalent to -S 'pacman -Qu' since
reinstalling a package doesn't change its install reason.
Provides/Replaces complicate this. We'd need to remove the old package, add the
replace package, manually set the install reason (if the original package was
installed asdeps) and have some kind of user confirmation for replacement of
packages during upgrades.
This is way too complicated. Several ways to handle this:
1) Bypass queue for system updates and use pacman code.
This one feels weird. Why not just use pacman -Su?
2) Ignore replace during upgrades.
Different behavior from pacman, not good.
3) Don't do update operations.
I don't really like this because its probably the most used pacman op, but at
the moment it feels like the cleanest solution. We could also leave out db
updates..
-----------
First Steps
-----------
Current state:
A package browser with the basics of navigation / filtering implemented. Messy
implementation.
Next up:
???
----------
Ideas/Open Questions/Misc
----------
Run as root/get root when needed??
List and queue pane both display packages. Do they use the same object (class)??