Differences

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

--- etc:30-gtk3-lpm [2022/06/01 07:42] – wikiadmin
+++ etc:30-gtk3-lpm [2022/06/23 21:41] (current) – removed wikiadmin
@@ Line 1: / Line 1: @@
-====== Missing features for the gtk3 lpm frontend ======
-This document lists features that might yet be implemented in glpm, the gtk3 front-end to lpm. It is divided into the sections
-  * important missing features
-  * important changes
-  * desirable missing features
-  * desirable changes
-  * wishlist
-The document is currently based on commit // f1cfe59//  of the gtk3 branch of //dalglish:/var/lib/git/lpm.git//.
-(Above commit name corresponds to the value retrurn by: **
- <font inherit/Courier New,Courier,monospace;;inherit;;inherit>git log -1 –pretty=format:%h</font> **)
-If any change or feature description has the remark (needs core change), the implementation would require a change to liblpm and/or plpm and therefore needs to be coordinated accordingly.
-===== 1. Important missing features =====
-There are currently no recognized important missing features
-===== 2. Important changes =====
-==== 2.1. Don't allow installation of multiple versions of a package ====
-The current view of available packages for installation also shows older versions of packages and the gui allows to select multiple versions and probably multiple varians of the same package, which is all not supported by plpm and might lead to unwanted installations. Furthermore, a change to the responsible property "show-old-versions" only takes effect after an application restart.
-The switch between showing old versions or not should rather be implement as some control above the list (checkbox,slider), while showing the newest should always be default.
-This of course has the consequence that upon changing the value the package list has to be re-read with a different value of newest. The chosen value of "newest/show-old-version" also changes what the user then can select:
-  * On newest=1/show-old-version=FALSE, the user may select any number of displayed packages for installation. Bar misssing dependencies in the catalogue and other technical problems this should then usually work
-  * On newest=0/show-old-version=TRUE, the user may then only select exactly one package and with all its name, version and variant passed to plpm
-As the second case is only a desirable missing feature (that is also not implemented in the flkt gui), the important change therefore only amounts to:
-  * removing the show-old-version property
-  * always set newest to 1
-==== 2.2. Shorten description in package lists or put Action column to the front of the list ====
-Currently, the package lists get their width determined by the longest available package descripiton. In the real word, this leads to very wide lists that cause the action checkbox to be hidden from the user and effectively prevent him to select any packages for installation. To fix this, there seem to be two solutions:
-  - Put the Action column to the front, leaving the description at the end
-  - Trim the description to maybe 60 chars
-I'd much prefer the first solution, as trimming might lead to unusable descriptions and sounds like more work.
-==== 2.3. Rename tabs and buttons, relocate tab headers, move actions to menu ====
-=== 2.3.1. Rename notebook tabs ===
-While the notebook tab names certainly make sense internally, the are IMHO not very user-friendly. I suggest renaming them to:
-  * "Updates" can be left as-is
-  * "Available" should be changed to "Install New Packages" or something like that.
-  * "Installed" should be changed to "Show Local Packages" or something like that.
-Im quite open to better ideas, but I think the hypothetical average user will look for what he wants to do and not the name of the needed data source for that.
-=== 2.3.2. Place tab headers on top instead of at the side, move Refresh and Cleanup to the menu. ===
-Guess, my eyes just prefer that, so if that is not too difficult, I suggest to move the whole sidebar over to the top of the lists.
-Concerning the placement of the Refresh and Cleanup buttons: As they are not clearly related to the below lists, it might be best to move them into a new Menu section "Actions". This would also have the advantage that any further actions (view install log) would probably be much easier to add.
-=== 2.3.3. Rename the "Apply" buttons ===
-I would prefer the Apply buttons to be named by respective action, "Update" and "Install"
-===== 3. Desirable missing features =====
-==== 3.1 Status bar ====
-A status bar like in the fltk gui would be very cool, to always display the last "important" output line printed by plpm, Currently, this corresponds to any line starting with "plpm: ".
-In the fltk gui this could be achieved quite easy in the Textbox's callback function plpm_fdh:
-<code>
-    line = strstr(s,"plpm: ");
-    if (line) {
-        plpm_status->clear();
-        t = s;
-        for (i=0; i <6; i++) {
-            t++;
-        }
-        plpm_status->add(t);
-    }
-</code>
-But from looking at the plpm output update code, there seems no easy way to grab selected output lines and throw them into another widget, so this is clearly rather a wish-list thing, as it seems to require a lot of code rewriting.
-==== 3.2. install one package with specified version and variant ====
-It is already mentioned under 2.1 that if the user chooses to display not only the newest available packages, but all available versions, he could then choose exactly one package from the list for installation.
-In that case, the frontend would have to supply not only the name but also both version and the eventual variant to plpm.
-It seems that the current implementation of plpm_execute has not yet implemented that functionality:
-<code>
-    for (GList *lp = packages; lp != NULL; lp = lp->next) {
-        LPI *lpi = lp->data;
-        g_string_append_c (command, ' ');
-        g_string_append (command, lpi->name);
-    }
-</code>
-In lpmsh.c, this is handled as follows:
-<code>
-            if (num_pkgs == 1) {
-                    if ( (optver != NULL) && ((optvar != NULL) ) ) {
-                        sprintf(optstr," -o version=%.100s,variant=%.100s ",optver,optvar);
-                    } else if (optver != NULL) {
-                        sprintf(optstr," -o version=%.100s ",optver);
-                    } else if (optvar != NULL) {
-                        sprintf(optstr," -o variant=%.100s ",optvar);
-                    }
-                    if (strlen(optstr)> 0) {
-                        strncat(syscmd,optstr,400);
-                    }
-                }
-                strcat(syscmd,packages[0]);
-            } else {
-                pkgstr = arr2str(packages,' ');
-                strncat(syscmd,pkgstr,1000);
-                free(pkgstr);
-            }
-</code>
-Therefore, a corresponding plpm_execute implementation would look something like that:
-<code>
-if (number_of_elements_in_packages == 1) {
-    GList *lp = packages;
-    LPI *lpi = lp->data;
-    if (lpi->variant != NULL) {
-        sprintf(optstr," -o version=%.100s,variant=%.100s ",lpi->version,lpi->variant);
-    } else {
-        sprintf(optstr," -o version=%.100s ",lpi->version);
-    }
-    g_string_append (command,optstr);
-    g_string_append (command,lpi->name);
-} else {
-    for (GList *lp = packages; lp != NULL; lp = lp->next) {
-        LPI *lpi = lp->data;
-        g_string_append_c (command, ' ');
-        g_string_append (command, lpi->name);
-    }
-}
-</code>
-This code would then also work for a downgrade of package, by just passing the desired lpi wrapped in this GList thing.
-==== 3.3. View a local lpk file ====
-While this clearly not a very important function, it should be quite easy to imlement: Have a "Open Package" entry in the file menu which then uses a file selection widget with wildcard *.lpk to get the filename of the package.
-This can then just be parsed by calling:
-<code>
-lpi = lpm_lpf_info(lpm,lpk_filename,1);
-</code>
-,where 1 tells the function to verify the signature.
-As displaying package details from an lpi is already implemted, that should then be all.
-==== 3.4. install one package from an lpk file ====
-plpm itself allows the installation of one (or more than one) specified package file, as the list of specified packages can also be a list of lpk files. By first getting the filename and maybe also verify its validity as described above, that filename could then just be passed to plpm install.
-But as the current plpm_execute code seems to expect a list of LPI package definitions and not filename, there would have some changes be made there. Therefore, this is maybe rather a wishlist thing.
-==== 3.5. Downgrade a package ====
-A downgrade of a package should take place at the GLPM_PACKAGE_VIEW_MODE_INSTALLED view, either by an option in a package's context menu (right-click), or on the package details window. In any case, to find out if a downgrade is even available, a call to lpm_findpkg_new will return the number of available versions and all the available package definitons:
-lpm_findpkg_new(LPM *lpm, LPC *lpc,char *lpk_name, char *variant,struct s_ekva **ext_attributes,int newvers,LPI ***lpi_list)
-The call to lpm_findpkg_new should be made with:
-  * lpm, lpc set to as usual
-  * lpk_name with the package name
-  * variant with the variant
-  *
-char *lpk_variant = NULL;
-. Desirable changes
-==== 4.1 Application startup ====
-===== 5. Wishlist =====
-  * verify package contents by hash (needs core change)
-- view install log \\
-- remove installed packages \\
-- downgrade installed packages \\
-- new LPM logo \\
-- application startup \\
-- update-only startup (maybe using notify) \\
-- group-privileged refresh \\
-- show package contents \\
-- verify package contents by hash \\
-- show dependend packages \\
-- debug mode \\
-- remove unneeded code
-.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.
-. 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 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….