This document lists features desired for a gtk3 front-end to lpm. It is structured into:

• General functionality and appearance
• Basic functionality
• Additional features

The document is based on commit 7167406d4c1c60a1a65fcdfd46dadc10dc690ec0 of the gtk3 branch of dalglish:/var/lib/git/lpm.git.

The gtk3 frontend should be called glpm (and glpm-update, for an update-only invocation), so it does not conflict with the current fltk-based xlpm frontend. Should be easy to change, I can do that myself…

Currently, glpm outputs stdout of any plpm call also on stdout, which is usually not visible when the program is invoked from the desktop.

If this is doable whithin resonable effort, glpm should implement some kind of output window like in fltk xlpm, displaying the stdout of any plpm invocation.

Whithin plpm, it is implemented that “high-level” messages are pre-prepended with “plpm: ”, this can be used to display progress on a status bar.

A settings dialogue backed by some ~/.config/glpm config file belongs in the nice-to-have section, possible settings would be:

• show_old_versions (false): also show older versions of available packages
• delete_dependencies (false): delete unused dependencies of deleted packages
• auto_cleanup (true): cleanup stagearea after successfull install or update
• auto_update (false): apply all available updates on invocation
• any other stuff I currently can't think of

Apart from the package-specific actions (install, update, remove), the following actions should be executable by the user, maybe by means of buttons:

• Cleanup: clean up the stage-area, corresponds to: plpm cleanup
• Refresh: refresh the package catalugue, corrensponds to: plpm refresh

The three main actions of glpm are:

• update: update all or selected package where an update is available
• install: install available packages that are not yet installed
• remove: remove installed packages that are no longer needed

In general, update is the most important function and should therefore get the initial main focus when starting glpm. As the listing of available updates is already implemented in current glpm, its details will not be described here further.

Due to the lack of versioned dependencies, an lpm-based system will usually be at its best state if all available updates are installed. Therefore, the action “update all” should be the one offered first to the user.

However, the user should also have the possibility to explicitely select one or more available updates.

At this moment, possible downgrades will not be offered at this place. They however could be offered when viewing details of an installed package, but this is clearly not the first priority.

The list of available updates does not need any search/filter functionality.

In order to install new packages, the user should be presented with a searchable/filterable list of available, not already installed packages, that can be retrieved by calling lpm_findpkg_new().

The most simple solution is to call the function with the flag newest set to 1, which will only display the newest version of any pacakge. In that case, the user may choose multipe packages for installation. This is the part that should be implemented first.

If a

The package lists….