AppImageLauncher icon indicating copy to clipboard operation
AppImageLauncher copied to clipboard

Add command line option to skip integration dialog

Open LeSnake04 opened this issue 4 years ago • 8 comments

Is your feature request related to a problem? Please describe. I am the maintainer of https://aur.archlinux.org/packages/cpod-appimage and it annoys me that on launch it alwys ask if i want to ingrate the package, even though I made an proper integration. If i would integrate it over the popup, it would make an second entry in menu, which doesnt get updates and confuse the user.

Describe the solution you'd like It would be really nice if I could add an command line option to the .desktop file which disables the popup like this appimagelauncherd --nointegration APPIMAGE-PATH

Additional context Related: #111

LeSnake04 avatar Aug 15 '21 14:08 LeSnake04

  1. What's the goal of that package? Do you just ship an AppImage inside an Arch package?
  2. Please provide a screenshot.
  3. Please provide the AppImageLauncher version.

If my assumption from 1. is correct, we can discuss ways how to avoid the integration dialog.

TheAssassin avatar Aug 15 '21 18:08 TheAssassin

  1. Yes, your assumbtion is correct. I did it to provide an way to get cpod working (the non appimage versions are currently broken) and while cpod techincally has an auto update function, https://aur.archlinux.org/packages/qmplay2-appimage (which i also maintain) doesnt have one
  2. I am not sure from what you want the screenshot: the popup?
  3. 2.2.0-5

LeSnake04 avatar Aug 15 '21 20:08 LeSnake04

"Suppressing" the dialog can be done, but I think that's not really necessary. Shipping the entire AppImage makes no sense in your case. How about --appimage-extracting the contents and packaging the resulting AppDir? The result will be just as portable. AppImageUpdate and other advanced AppImage features (just like desktop integration) are most likely not needed in your case anyway?

TheAssassin avatar Aug 15 '21 20:08 TheAssassin

I tried it already and it turned out to be a bad idea for 2 reasons:

  1. The package size grew by 300% (50MB to 150 mb)
  2. It doesn't work since it tries to load the library's from the root /usr/share and AUR packages (just like any other package) should NEVER EVER install third party libraries in the system path, since it will cause file conflicts if the real library is already installed or when the real library gets installed later

Thats why pretty much appimage based packages in the AUR install the appimage directly.

LeSnake04 avatar Aug 15 '21 23:08 LeSnake04

Turned out some packages work with the extracted AppImage. I didn't took a closer look yet but I asume these packages can only do it because eighter:

  1. the Appimage has no library packaged into it
  2. They install the library from the repo/other AUR packages, making the install process way longer, may install versions incompatible with the app (Whats pretty much guarantied in old AppImages ) and risking the installation being broken if other packages break or get removed.
  3. It MAY be possible to install the packaged libraries without putting it into /usr/lib/ but I assume the difficulty of telling the system to not use the system library strongly varies between each program language and how the app is programmed. I had problems with this in Python once: after I installed the program with pip to test my setup.py, Python refused to use the project files instead of the copy in the system path. Now I have to install it after every single change to the system path. I am VERY sure this would be a lot of pain to set up especially in compiled and closed source applications

Long story short: Its possible to use the extracted AppImage, but would require a lot of work to set up and maintain and defeats the Whole purpose of AppImages

You would do the AUR community a great favor by implementing this feature

LeSnake04 avatar Aug 19 '21 11:08 LeSnake04

export APPIMAGELAUNCHER_DISABLE=true

before the command is currently the only way

jpenguin avatar Aug 30 '21 02:08 jpenguin

export APPIMAGELAUNCHER_DISABLE=true

before the command is currently the only way

Thanks for the tip! This is actually a good solution for my problem!

LeSnake04 avatar Aug 30 '21 13:08 LeSnake04

Turned out some packages work with the extracted AppImage. I didn't took a closer look yet but I asume these packages can only do it because eighter:

  1. the Appimage has no library packaged into it
  2. They install the library from the repo/other AUR packages, making the install process way longer, may install versions incompatible with the app (Whats pretty much guarantied in old AppImages ) and risking the installation being broken if other packages break or get removed.
  3. It MAY be possible to install the packaged libraries without putting it into /usr/lib/ but I assume the difficulty of telling the system to not use the system library strongly varies between each program language and how the app is programmed. I had problems with this in Python once: after I installed the program with pip to test my setup.py, Python refused to use the project files instead of the copy in the system path. Now I have to install it after every single change to the system path. I am VERY sure this would be a lot of pain to set up especially in compiled and closed source applications

Long story short: Its possible to use the extracted AppImage, but would require a lot of work to set up and maintain and defeats the Whole purpose of AppImages

You would do the AUR community a great favor by implementing this feature

I just realise I can just use the AppRun from the extracted AppImage...

But the size point still stands.

LeSnake04 avatar Sep 29 '21 19:09 LeSnake04