"AM" 8.2

System icon theme support (optional)

By default, apps installed via "AM"/"AppMan" have a "Desktop Entry" for the icons that points to the full path to the icon (without extension) in the .desktop file, in order to ensure the forced presence of icons within the application menu.

For example, here is how normally "AM"/"AppMan"'s installation scripts will made the .desktop file pointing to the icon:

avidemux in "AM"	anydesk in "AppMan"

So no way to implement an icon theme pack support... until this release!

Wait a moment! We have not implemented theming "by default" but have made it optional, thanks to the new option "icons" or "--icons"!

USAGE:

am icons $PROGRAM
am icons --all

or

appman icons $PROGRAM
appman icons --all

In brief

You can specify the name of one or more applications for which you want to enable customization (recommended) or apply the change to all applications by adding only the "--all" flag (not recommended).

Technical details

The option uses "sed" to zero out the icon path inside the .desktop file (entry "Icon="), and also creates the symbolic link (with extension) for all installed apps, in $HOME/.local/share/icons/hicolor/scalable/apps (if a file with the same name already exists, it will NOT be overwritten).

Unneeded icon's symlinks

If you remove an app or use this new command, "AM/"AppMan" will automatically detect if there are broken symbolic links in that location and remove them.

Examples

In this example, I will change the icon only to "lxtask", using the one from my personal icon theme, you will see that the .desktop file will have the icon path changed. To update, you need to open the theme manager for the icons (in my case, the XFCE one).

simplescreenrecorder-2024-09-05_05.03.34.mkv.mp4

NOTE, only "AM" needs root privileges to modify the .desktop file, as it is in /usr/local/share/applications, "AppMan" does not have these problems.

In this other example I will show how icons are added via symlink, using "AppMan" with four AppImages: Anydesk, Chromium and the two "metapackages" Kdegames and Kdeutils (containing dozens of applications). You will also notice how the icons are automatically removed if I remove the related applications. I will first apply the change to "kdegames" and then I will use the "--all" flag.

simplescreenrecorder-2024-09-05_05.41.29.mkv.mp4

This new option works especially well with AppImages, since classic portable programs (see Firefox and Thunderbird) often have their icons in different directories than those commonly used in most scripts.

I hope this option will make customization maniacs happy.

Recommendations:

• the $HOME/.local/share/icons/hicolor/scalable/apps directory will be created automatically by starting this option, but not all Desktop Environments are able to support these specifications, check if your DE supports that path;
• the icons in the icon pack must have the same name as the applications, those provided via "AM"/"AppMan" in the "icons" directory of the application are renamed like this;
• every new app installed will have the default settings, with the .desktop file pointing to the "icons" directory of the application, this being the safest path to guarantee launchers with icons. Use the option again after installing the app.

What's Changed

• database.am refactoring by @ivan-hc in #915
• Update install.am: refactoring by @ivan-hc in #916
• Update management.am: refactoring by @ivan-hc in #917
• use while instead of for loop sandboxes.am by @Samueru-sama in #919
• Update sandboxes.am: refactoring by @ivan-hc in #920
• Fix modules source in developer mode by @ivan-hc in #923
• Add .png or .svg symlinks to icons management.am by @Samueru-sama in #925
• Fix modules usage from 3rd-party repos by @ivan-hc in #926
• "AM" 8.2: added an option to remove icon path and allow the use of custom icon themes by @ivan-hc in #924

Full Changelog: 8.1.1...8.2

"AM" 8.1.1

Minor update about BASH/ZSH completion usage

The BASH/ZSH completion file is now in ~/.local/share/bash-completion/completions, named "am" or "appman", depending if you use "AM" or "AppMan", so they have a dedicated file and no more need the old ~/.bash_completion.

On first use, if the old ~/.bash_completion file exists, the line referring to AM or AppMan will be automatically removed. If you don't need that file, you can safely remove it.

• Move completions file to ~/.local/share/bash-completion/completions by @ivan-hc in #905

New Contributors

• @marco-calautti made their first contribution in #906

Full Changelog: 8.1...8.1.1

"AM" 8.1

"AppMan" can install apps also in directories that are not the $HOME, "AM" can be packaged for distributions and a new option -ia for AppImages is now available!

As the title suggests, this release brings with it three very important new features, let's proceed in order.

1. "AppMan" can install apps also in directories that are not the $HOME

From now on you can choose a directory other than $HOME for the installation of your applications, even an external partition, as long as you have permissions to write to it.

This new feature makes "AppMan" already a step forward compared to "AM".

Thanks to @Samueru-sama for this improvement!

2. "AM" can be packaged for distributions

For those who decide to package "AM" for the repositories of some distribution, it is necessary to take into account this function inside the APP-MANAGER script, which is the heart of "AM"/"AppMan":

# DETERMINE WHEN TO USE "AM" OR "APPMAN"
if [ "$(realpath "$0")" = "/opt/am/APP-MANAGER" ]; then
	_am
	mkdir -p "$MODULES_PATH" || exit 1
elif [ "$(realpath "$0")" = "/usr/bin/am" ]; then
	_am
	AMPATH="$AMCACHEDIR"
	MODULES_PATH="/usr/lib/am/modules"
else
	_appman
fi

the above function specifies that if the "am" command is in /usr/bin, the "AMPATH" variable will be set to a writable directory (in our case we used "AMCACHEDIR", the $HOME/.cache/am directory) while the "MODULES_PATH" variable will be set to the system directory "/usr/lib/am/modules" you created, thus overriding the default values ​​of "AM".

for this to work, you need to rename the "APP-MANAGER" script to "am" and place it in /usr/bin, while the "modules" directory must be placed in /usr/lib/am. Here is how a package structure should look like, according to the definitions currently in force:

/usr/bin/am
/usr/lib/am/modules/database.am
/usr/lib/am/modules/install.am
/usr/lib/am/modules/management.am
/usr/lib/am/modules/sandboxes.am
/usr/lib/am/modules/template.am

the above scheme has already been tested on Debian Stable, a demo video is available here.

For this "special" redistribution, module updates and the CLI itself will be disabled, which will instead have to be managed by the package manager in use (APT, DNF, Emerge, YAY...).

NOTE, the above scheme may be changed, according to the distribution packagers' decisions. Suggestions for improving the implementation are welcome.

3. New option -ia for AppImages is now available

Like the option -i/install, but for AppImages only! Its now available the new option "-ia" or "install-appimage"!

USAGE:

am -ia {PROGRAM}
am -ia --debug {PROGRAM}
am -ia --force-latest {PROGRAM}

or

appman -ia {PROGRAM}
appman -ia --debug {PROGRAM}
appman -ia --force-latest {PROGRAM}

In this example, I'll run the script brave-appimage but running brave, that instead is the original upstream package:

install-appimage-2024-08-29_17.49.07.mkv.mp4

in the video above I first launch a "query" with the -q option to show you the difference between brave and brave-appimage, and then -q --appimages to show you only the appimages from the list.

All the new option "-ia" does is to check on the AppImage's list if the "argument" exists, if not, another check will be done by adding "-appimage" at the end of the argument. If no argument is found, the command -i will not not be launched, while if the argument exists, the option -i will take care of the installation of the script and also of the flags --debug and --force-latest, if they exist.

NOTE: by definition, the AppImages themselves "are not installed", but by installation we of the "AM" team mean adding the package, with its symbolic link, the version file, the icon directory and the script to update the application all, overall, in the dedicated paths. Generalizing, and above all for practical reasons, of language and syntax, we simplify the whole thing by calling this option "install-appimage", or simply "-ia", in PacMan/YAY style.

What's Changed

• allow appman to work outside $HOME take 2 by @Samueru-sama in #889
• improve detection of $BINDIR APP-MANAGER by @Samueru-sama in #890
• fix conversion of old appman config APP-MANAGER by @Samueru-sama in #891
• Fix appman mode usage in AM for unprivileged users by @ivan-hc in #892
• Update CONTRIBUTING.md by @ivan-hc in #893
• "AM" 8.1 by @ivan-hc in #894

Full Changelog: 8...8.1

"AM" 8

Let's improve for the future!

There are some major changes in this release, and they were already announced in the three pre-releases of the past few days. Here's what's changed.

BASH/ZSH completion, by default, and rootless

The bash completion file will be updated locally, in $HOME, as it already happened with "AppMan", the same will happen with "AM". But for both modes, the change will be dynamic, so you can constantly update the file responsible for the keywords to use.

"AM" users are advised to remove the old "/etc/bash_completion.d/am-completion.sh" file used previously, it is no longer needed.

Changed destination for lists and configuration files, locally!

Both "AM" and "AppMan" will share the new "AM" directory that will be created in ~/.local/share, and in which the lists will be updated, both of the applications and of the keywords to be used in the BASH/ZSH completion. And not only that, all the configuration files for betatests and third-party repositories will be saved there.

The .cache directory is being retired

From now on, versions and info about installed apps, and the processes of installing scripts from the database will be done in ~/.cache/am and ~/.cache/appman, so that any dedicated client, like BleachBit, can handle temporary files.

To remove old files and the old .cache directory previously used, run "AM" or "AppMan" with the -c option.

Halving of modules

The modules have been reduced from 10 to 5. This results in faster update speed of "AM" and "AppMan".

Size

This release come with 1,286 additions and 2,295 deletions in the code, so "AM" and its modules are overall 3/4 of the previous version.

More readable help message

Not only has the help message (option "-h") been simplified, but colors and more complete formulas have been added, which show in concrete terms how to use the commands.

help-2024-08-26_04.56.12.mkv.mp4

Replacement of "wget" in favor of "curl" for some functions

The functions related to downloading scripts and modules have undergone the replacement of "wget" in favor of "curl", so that you can also easily manage offline files. Why? It is soon explained in the next paragraph.

Offline/online repos, your own fork or a third-party one... to manage them is simplier!

Completely rewritten the procedure for creating and managing third-party repositories, made easier with simple commands to use. You can drag a directory with the same structure as this repository or a link to a branch (in "RAW") to a fork or a repository similar to this one, as long as the structure is similar, and you will be able to install applications, consult lists and update from there, as long as the selected repository is active. You can learn more in the dedicated section of the README, or run the "-h" option and search for "newrepo" or "neodb". In the meantime, here is a demo video:

newrepo-2024-08-26_05.01.03.mkv.mp4

Start of distribution packager support

"AM" is always meant to be installed and used in /opt/am with a symbolic link in /usr/local/bin/am. This will not change, but it will also be supported by alternative paths that will be selectable by those who decide to implement "AM" in their distro. Other improvements in this regard will be added in the coming days, or weeks.

Conclusions

The most important aspect of this release is to bring "AM" to a much more open level, since it is designed to install applications at system level and update them without root privileges. We have done the first step now, moving the bulk of the files normally used from "$AMPATH" (the APP-MANAGER directory) to ~/.local/share/AM, shared with "AppMan". Now we only have to work on APP-MANAGER and the few remaining modules, to allow the use of "AM" to all privileged users, not just the owner of "AM".

Bringing some files known to be managed only by the owner of "AM" to a lower level is already a step forward towards the extensibility of this CLI, which from now on will have an easier path to new implementations.

Thanks for the support, and thanks to @Samueru-sama who helped me a lot!

Full Changelog: 7.8.1...8

"AM" 8beta1

• Day 1 https://github.com/ivan-hc/AM/releases/tag/8alpha1
• Day 2 https://github.com/ivan-hc/AM/releases/tag/8alpha2

Third day of improvements:

• modules are now only 5
  

• Option "help" or "-h" improved, with colors and shorter messages

help-2024-08-25_20.27.17.mkv.mp4

• Option "newrepo" or "neodb" is now totally rewrited. New support for third-party repositories, managed directly from the main CLI, its enough to use the suboption add followed by the path to an offline directory or a "RAW" URL that will be added to a list, needed to select one of the repos that will replace the main one. To enable/disable it use on/off

newrepo-2024-08-25_20.32.43.mkv.mp4

to allow this behaviour, some modules and commands have been converted to curl usage.

To test the new features, run the command

am --devmode-enable

or

appman --devmode-enable

the release its quite ready, now its time to finalize some little details before it become Stable.

Please open a discussion or a issue if you have a suggestion to improve this release. Thank you for your attention.

Full Changelog: 7.8.1...8beta1

"AM" 8alpha2

Day one, see https://github.com/ivan-hc/AM/releases/tag/8alpha1

In the day 2 of this work, we have reduced the number of modules from 10 to 7:

• database.am contains '-f, '-a', '-l' and '-q'
• management.am contains '-b', '--rollback', '--launcher', 'lock', 'unlock', 'nolibfuse', '-o' and 'remove'/'-R'/'-r'
• install.am contains '-i', '-e' and '-d'
• option 'apikey' has been moved to APP-MANAGER
• other modules have been almost untouched

Start reworking on single options, now "AM" has a better detection of its status, to be used as "AM" or "AppMan", and we are preparing made it installable/usable from /usr/bin, for furter implementations in distro packages.

Removed references about third-party repos and neodb from all options using them, since we are starting on a total rework of the support for third-party repositories, by merging options "neodb" and "newrepo", for now still in the "devtools.am" module.

This pre-release come with 986 additions and 1,601 deletions.

We are planning to move the modules to a different directory from /opt/am/modules, please open a discussion or issue if you have any ideas.

For now, it is certain that the lists and configuration files will be moved from /opt/am to ~/.local/share/AM, for a shared use of the lists between AM and AppMan, while the "cache" files (installation scripts running, information files about installed apps and their versions) will be moved to ~/.cache/am and ~/.cache/appman

If you are curious to test the future AM 8, run

am --devmode-enable
am -s

or

appman --devmode-enable
appman -s

and help us with your feedback, it will be much appreciated.

Full Changelog: 8alpha1...8alpha2

"AM" 8alpha1

There are some changes in progress that will bring "AM" to a much more versatile use in terms of permissions:

• processes will happen in ~/.cache/am instead of /opt/am/.cache
• lists will be saved and consulted in ~/.local/share/AM, a directory that will be common to both "AM" and "AppMan"
• BASH/ZSH completion will be enabled by default, and managed via the ~/.bash_completion file (for BASH), in a completely "rootless" way, and in order to extend the arguments to be used dynamically

To test the changes, you can run the following command

am --devmode-enable

in order to start the tests that will release "AM" 8.

See the development branch for more https://github.com/ivan-hc/AM/tree/dev

Status until this pre-release main...snapshot-20240823-am-8-pre-alpha1

"AM" 7.8.1

Refactoring and little improvements

Improved functions to detect apps installed with scripts having a different name, about/-a and sync/-s above all.

Also, option about/-a has colors now.

And also the option --sandbox has been improved, by @Samueru-sama allowing you to sandbox/unsandbox more AppImages at same time.

Also done a massive code refactoring and lightweighting of *.am modules.

Full Changelog: 7.8...7.8.1

"AM" 7.8

Goodbye "libfuse2"!

Improved the option nolibfuse, usage:

am nolibfuse $PROGRAM

or

appman nolibfuse $PROGRAM

thanks to the new appimagetool implementation (at https://github.com/AppImage/appimagetool) now it is possible to convert ALL old AppImage packages still requiring the EOL "libfuse2" library!

Just one shot! No second chance!

In this example, I'll convert Libreoffice and Kdenlive:

get-rid-of-libfuse2-2024-08-18_22.09.08.mkv.mp4

As you can see, the file sizes are also smaller than before.

This process only works for old AppImages that still depend on "libfuse2", other files will be ignored.

The original AppImage will be extracted using the --appimage-extract option, and then repackaged using appimagetool from https://github.com/AppImage/appimagetool

Updating converted AppImages

The nolibfuse option adds the following lines at the end of the AM-updater script

echo y | am nolibfuse $APP
notify-send "$APP has been converted too! "

or

echo y | appman nolibfuse $APP
notify-send "$APP has been converted too! "

so if an update happens through "comparison" of versions, the converted AppImage will be replaced by the upstream version and then the nolibfuse option will automatically start the conversion (prolonging the update time, depending on the size of the AppImage).

In this example, I update all the apps, including the original Avidemux, that is an old Type2 AppImage:

update-converted-appimages-2024-08-18_21.09.53.mkv.mp4

Instead, if the installed AppImage can be updated via zsync, this may no longer be updatable, anyway a solution may be the use of appimageupdatetool, at https://github.com/AppImageCommunity/AppImageUpdate .

SPOILER ALERT

New improvements for updates will be added in the next releases, thanks to the amazing work of @Samueru-sama : STAY TUNED!

---

Improved options to remove the applications

Added colors and reduced messages during the removal of applications, in -r or remove...

...and -R

---

Among other changes

Refactoring and size reduction in the "management.am" module, responsible for the above mentioned nolibfuse, -r/remove and -R options, but also responsible of the -b/backup, -o/overwrite, downgrade/--rollback, lock and unlock options.

Thanks to @Samueru-sama for testing nolibfuse in AppMan and on sistems where desktop-file-validate is not installed.

What's Changed

• Remove zsync from template by @Samueru-sama in #851
• sync by @ivan-hc in #855
• "AM" 7.8: goodbye libfuse2! by @ivan-hc in #856

Full Changelog: 7.7...7.8

"AM" 7.7

Suspicious applications? Report them!

The installation process will take into account installation scripts belonging to applications that have little transparency in how they were built, therefore coming from repositories or websites that only publish the app and not the source code.

Each installation script of this type will have, on line 2, this "flag": # spooky

installation scripts with this branding will be intercepted at installation time.

Anyone among you who is aware of applications of dubious transparency can do a Pull Request by adding the flag above, as shown in the screenshot.

A message will appear to let you choose to install them or not (default "N").

This is the message that will appear:

And that's the only big change for this release!

Wait...

What? Do you notice anything different?

Yes, I added color to the installation process. I hope you like it:

simplescreenrecorder-2024-08-15_20.46.08.mkv.mp4

Among the other changes, the "install.am" module has been refactored and "SUDOCOMMAND" is about to be changed to "SUDOCMD".

What's Changed

• Introduce check for spooky scripts, and some refactoring by @Samueru-sama in #849
• "AM" 7.7: check "spooky" AppImages before installing them, plus "colored installation" by @ivan-hc in #850

Full Changelog: 7.6.2...7.7