[Feature Request] Please improve the VRCX Linux Appimage, and generally how VRCX updates. #543

New Issue

MrUnknownDE · 2026-04-05T16:20:43+02:00

MrUnknownDE commented

2026-04-05 16:20:43 +02:00

Originally created by @pinbuck on 2/19/2025

Keep in mind these are just user feedback suggestions after using the linux appimage build for a few months, there may be some errors in what I say on this list.
That being said, here's a list of ideas, fixes, improvements, and feature requests I came up with for the appimage and updating system:

Unrelated note, please provide instructions on the README to users on how to delete VRCX from their home folder on Linux, or an Uninstall button that states what it's removing and user confirmation.

All 4 of these feature requests will help reduce problems caused by updating, and user reports caused by the app being out of date.

Mention in the README that VRCX is available for install from Scoop and any other repos I didn't find.
These can provide users an ideal method to update if users don't want to use the built-in auto-updater.
Winget is popular and built-in to Windows, is it possible VRCX could be made available on winget?

Executing the downloaded appimage bundle shouldn't create another appimage unless it needs to update itself.

There really shouldn't have to be a permanent location for the VRCX appimage itself.

The most popular electron appimages on Linux keep the immediate home directory untouched, and instead use clean locations such as
~/.cache/ , ~/.local/ or ~/.config/ , but leave the location of the portable appimage to the user's discretion.

This simplifies the install process, and doesn't reinstall the appimage to ~/Applications/ if the user moves the appimage.

Appimage bundles should be portable, and ideally shouldn't always be used as a pseudo one-button for installing a prebuilt folder, which the user has to run by clicking again anyways.

If the software isn't actually single-click, it would be better to give users a folder that contains the prebuilt binary with its dependencies next to it, similar to how firefox forks provides a tarball on their website as an option.
https://librewolf.net/installation/linux/#appimage

If the tarball folder route is chose, ideally it should be a clean and portable folder that's easy to understand for users, and well-compacted like what Librewolf's team does.

The VRCX Linux appimage should be compatible with AppImageLauncher, and have an easy way to toggle application self-updating on/off similar to other electron apps
https://github.com/TheAssassin/AppImageLauncher (What appimage users use to update all their appimages, compacting many updaters into one simple system

https://github.com/vrcx-team/VRCX/issues/1114

If you do choose to go the route of adding your own auto-updating system to the Linux version, please fix how the appimage is handled by improving the current install system, and make it compatible with AppImageLauncher.

Built-in appimage updating is convenient for developers and average users on Linux, but not necessary unless it's very simple and can be toggled on or off.

New optional auto-updating system for the Linux appimage

VRCX doesn't seem to currently have an auto-updating method, or it's not very clear if it does or not.

For example, here's how a linux electron appimage bundles handle updating in a simple and clean way:

Vesktop has an auto-updater baked into the appimage which can be toggled within it's settings similar to other electron apps on Linux.
https://github.com/Vencord/Vesktop

This is a similar electron app that places a folder within ~/.cache called "vesktop-updater", it contains info about version and will use it as a temporary location to grab the latest version of the appimage, and then switches out the location of the current appimage and copies it's user-set permission to execute it.

*Originally created by @pinbuck on 2/19/2025* Keep in mind these are just user feedback suggestions after using the linux appimage build for a few months, there may be some errors in what I say on this list. That being said, here's a list of ideas, fixes, improvements, and feature requests I came up with for the appimage and updating system: Unrelated note, please provide instructions on the README to users on how to delete VRCX from their home folder on Linux, or an Uninstall button that states what it's removing and user confirmation. All 4 of these feature requests will help reduce problems caused by updating, and user reports caused by the app being out of date. 1. Mention in the README that VRCX is available for install from Scoop and any other repos I didn't find. These can provide users an ideal method to update if users don't want to use the built-in auto-updater. Winget is popular and built-in to Windows, is it possible VRCX could be made available on winget? 2. Executing the downloaded appimage bundle shouldn't create another appimage unless it needs to update itself. There really shouldn't have to be a permanent location for the VRCX appimage itself. The most popular electron appimages on Linux keep the immediate home directory untouched, and instead use clean locations such as ~/.cache/ , ~/.local/ or ~/.config/ , but leave the location of the portable appimage to the user's discretion. This simplifies the install process, and doesn't reinstall the appimage to ~/Applications/ if the user moves the appimage. Appimage bundles should be portable, and ideally shouldn't always be used as a pseudo one-button for installing a prebuilt folder, which the user has to run by clicking again anyways. If the software isn't actually single-click, it would be better to give users a folder that contains the prebuilt binary with its dependencies next to it, similar to how firefox forks provides a tarball on their website as an option. https://librewolf.net/installation/linux/#appimage If the tarball folder route is chose, ideally it should be a clean and portable folder that's easy to understand for users, and well-compacted like what Librewolf's team does. ![Image](https://github.com/user-attachments/assets/957d1a1b-3c9d-4aba-ac42-b7f901a66fa5) 3. The VRCX Linux appimage should be compatible with AppImageLauncher, and have an easy way to toggle application self-updating on/off similar to other electron apps https://github.com/TheAssassin/AppImageLauncher (What appimage users use to update all their appimages, compacting many updaters into one simple system https://github.com/vrcx-team/VRCX/issues/1114 If you do choose to go the route of adding your own auto-updating system to the Linux version, please fix how the appimage is handled by improving the current install system, and make it compatible with AppImageLauncher. Built-in appimage updating is convenient for developers and average users on Linux, but not necessary unless it's very simple and can be toggled on or off. 4. New optional auto-updating system for the Linux appimage VRCX doesn't seem to currently have an auto-updating method, or it's not very clear if it does or not. For example, here's how a linux electron appimage bundles handle updating in a simple and clean way: ![Image](https://github.com/user-attachments/assets/1b696b71-502e-4535-910c-f10f5da48b07) Vesktop has an auto-updater baked into the appimage which can be toggled within it's settings similar to other electron apps on Linux. https://github.com/Vencord/Vesktop This is a similar electron app that places a folder within ~/.cache called "vesktop-updater", it contains info about version and will use it as a temporary location to grab the latest version of the appimage, and then switches out the location of the current appimage and copies it's user-set permission to execute it.

MrUnknownDE closed this issue

2026-04-05 16:20:43 +02:00

Sign in to join this conversation.

No Label Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Done Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/VRCX#543