change over nativefier apps to webapps

[theofficialgman]

resolves #2321
resolves #2439

[theofficialgman]

snapdrop is also giving the "too old" error now btw

[theofficialgman]

the main issue I see with this is chromium-browser is not actually an apt package anymore in ubuntu focal+ and doesn't exist in pure debian. so all of these apps would be only piOS and bionic compatible. that is simple enought to modify in the categories files so they are hidden on other platforms

[theofficialgman]

another alternative to this "webapp" system is to use https://github.com/gluon-framework/gluon which is kinda a cross between electron and webapps. gluon can still use nodejs packages but uses the system chromium/firefox install https://github.com/gluon-framework/gluon#comparisons

[theofficialgman]

nativefier is now unmaintained. even more so a reason to go through with finalizing this
nativefier/nativefier#1577

[theofficialgman]

@Botspot thoughts? this should also work with chromium-browser package from ubuntu that installs a snap though I have not tested that.

[Botspot]

A few issues I noticed when reviewing the menu launchers for these apps: (snapdrop's launcher provided below for quick reference)

echo "Creating menu button..."
echo "[Desktop Entry]
Name=Snapdrop
GenericName=Local File Sharing
Comment=Local file sharing in your browser. Inspired by Apple's Airdrop.
Exec=chromium-browser %U --user-data-dir=$HOME/.config/webapps/snapdrop --app=https://snapdrop.net/
Icon=$(dirname "$0")/icon-64.png
Terminal=false
StartupNotify=true
Type=Application
Categories=Utility" | sudo tee /usr/local/share/applications/Snapdrop.desktop || error "Failed to create menu shortcut!"

• The %U is from the original chromium-browser launcher and is a placeholder for a url. This is used by xdg-open when a link is clicked in the OS. I think leaving it here is unnecessary.
• tee will output to stdout. It needs >/dev/null
• The menu entry will be global, but the config folder will be specific to the current user's home directory, meaning that the launcher will appear for other users but will not be able to access its config folder.
• Same for the icon. Probably better switch the .desktop files to be in ./local/share/applications, or copy the icons to global locations

[theofficialgman]

• The %U is from the original chromium-browser launcher and is a placeholder for a url. This is used by xdg-open when a link is clicked in the OS. I think leaving it here is unnecessary.

yeah thats correct it should be removed

• tee will output to stdout. It needs >/dev/null

will do

• The menu entry will be global, but the config folder will be specific to the current user's home directory, meaning that the launcher will appear for other users but will not be able to access its config folder.

maybe we should wrap the command so it is executed by bash. that way the $HOME variable content doesn't have to be hardcoded in the .desktop file and instead $HOME can be evaluated at runtime. that way every user will have their own config folder. I really wish the execution of .desktop files could resolve variables typically available in bash environment on their own but they cannot.

alternatively we could create a wrapper script for each webapp that the .desktop file calls instead of embedding bash in the .desktop file. that is what I am leaning towards.

eg:
/usr/local/bin/snapdrop

#!/bin/bash

chromium-browser --user-data-dir=$HOME/.config/webapps/snapdrop --app=https://snapdrop.net/

/usr/local/share/applications/Snapdrop.desktop

[Desktop Entry]
Name=Snapdrop
GenericName=Local File Sharing
Comment=Local file sharing in your browser. Inspired by Apple's Airdrop.
Exec=/usr/local/bin/snapdrop
Icon=snapdrop
Terminal=false
StartupNotify=true
Type=Application
Categories=Utility

while copying the icons to
/usr/local/share/icons/hicolor/64x64/apps/snapdrop.png and /usr/local/share/icons/hicolor/24x24/apps/snapdrop.png which are the actual correct global placement for non-apt managed global png icon paths.

• Same for the icon. Probably better switch the .desktop files to be in ./local/share/applications, or copy the icons to global locations

the home directory (and all files in it) have read and execute permissions for all users (755) so it would generally work to reference a specific users icon file. regardless it is minimal extra steps to install the icon globally so that can be done as shown above.

[Botspot]

Once these changes are made I think this is ready to merge. Brace yourself for some users to request a choice of web browser, but unless that becomes a frequent request, I think it would be better to suggest these users create their own web apps on their own time.