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 2397669e of the gtk3 branch of dalglish:/var/lib/git/lpm.git.

(Above commit name corresponds to the value retrurn by: git log -1 –pretty=format:%h )

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.

The current implementation displays an additional popup-window of plpm's output in a new windows. If doable within reasonable effort, it would be nicer if the output would be implemented as block below the main area.

A maybe easy solution that springs to mind is that glpm would create a tempfile (/tmp/glpm-plmp-$PID.out) at start and then redicrects all plpm stdout (and stderr) to this file (“/usr/sbin/plpm $ACTION $OPTIONS $PACKAGES » /tmp/glpm-plmp-$PID.out 2>&1”).

The plpm output block could then be just implemented as a scrollable window over said file, always displaying its bottom, like a “tail -f” on a shell.

Currently, glpm performs a cataologue update at startup before displaying its main window. As the refresh may take some time, especially when using the lpc-http backend, it might be nicer if glpm only does the previous initialisation steps before and performs the refresh after displaying the main window. It then could also already display above plpm otubut block, and above maybe just a cool png picture, configurable at build time.

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.

The package lists….