Differences

This shows you the differences between two versions of the page.

--- etc:30-gtk3-lpm [2022/05/24 16:13] – wikiadmin
+++ etc:30-gtk3-lpm [2022/06/23 21:41] (current) – removed wikiadmin
@@ Line 1: / Line 1: @@
-====== Features for the gtk3 lpm frontend ======
-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 //26fcb2ec1873cb6aefe4a4160868c4e1e5b3fc22//  of the gtk3 branch of //dalglish:/var/lib/git/lpm.git//.
-===== 1. General functionality and appearance =====
-==== 1.1 Naming ====
-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…
-==== 1.2 Output of privileged functions ====
-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.
-==== 1.3 Proposal for output of privileged functions ====
-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.
-==== 1.4 Application startup ====
-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.
-==== 1.5 Settings ====
-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
-==== 1.6 Actions ====
-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
-===== 2. Package actions =====
-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
-==== 2.1. Update ====
-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.
-==== 2.2 Install new packages ====
-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()**.
-=== 2.2.1 Install multiple packages ===
-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….