Skip to content

Would it be possible to build two separated versions of AppImage for X11 and Wayland?  #1221

Closed

Description

@gusbemacbe

Hello!

I usually switch from X11 to Wayland and from Wayland to X11. I often use @federico-terzi's Espanso. The problem is that I had to install two versions of Espanso, one designed for X11, another for Wayland.

I use Espanso-X11.AppImage when I switch to X11, and use /usr/bin/espanso compiled and built from a source without X11 when I switch to Wayland, the concern is that, I will always receive an inconvenient Espanso advice about incompatibility when I switch to a different graphic environment because of espanso.service that points to /usr/bin/espanso. I had to use espanso service start --unmanaged.

Imagine that I am switching to i3 that is an X11 window manager or to Sway that is a Wayland window manager, and writing the following code to the i3/Sway config file or on a global Bash/ZSH file):

VERIFY_ENVIRONMENT=$(echo $XDG_SESSION_TYPE)

if [[ $VERIFY_ENVIRONMENT == "x11"]]; then
    ~/Apps/Espanso-X11.AppImage
     espanso service start --unmanaged
else
    ~/Apps/Espanso-Wayland.AppImage
     espanso service start --unmanaged
fi

Is it possible?

Activity

  1. probonopd commented on Oct 14, 2022

    @probonopd
    Member

    I don't know much about Wayland except that it is not 100% compatible with X11, makes screen sharing complicated, and never works with full performance on my Nvidia based systems, so forgive me if this is a stupid question, but:

    Why are there two different versions of the application needed? Wayland proponents tend to claim that X11 applications can run in XWayland.

    Of course the author of the Espanso AppImage could make two separate AppImages, but that is not what I'd recommend.

    If there are really two different versions of the application needed, then it would be best if the author of the Espanso AppImage would put both versions into the same AppImage, add an if statement in the AppRun, and run the Wayland version of the application in case Wayland is detected to be running on the system. As a result, users could just run the AppImage and it would execute the version needed for their particular window server without the user having to deal with multiple AppImages.

  2. gusbemacbe commented on Oct 15, 2022

    @gusbemacbe
    Author

    Why are there two different versions of the application needed? Wayland proponents tend to claim that X11 applications can run in XWayland.

    Maybe @federico-terzi can explain.

    Espanso built for X11 will not work on Wayland due to xclip. Wayland asks for wl-copy.

    When I ran Espanso-X11.AppImage on Wayland, I received a warning about the incompatibility.

    Not only Espanso, Autokey also doesn't support Wayland because of xclip.

    @microsoft's VSCode can run on both X11 and Wayland without needing to build two different versions because it can detect the XDG session and switch to xclip or wl-copy.

    @Mange's rofi-emoji can detect if it is X11 or Wayland, and switch to a copy variable assigned to X11 or Wayland's dependency, then it doesn't need two different versions: https://github.com/Mange/rofi-emoji

  3. BlueDrink9 commented on Oct 15, 2022

    @BlueDrink9

    @gusbemacbe it's a little bit rude to tag people in unrelated issues. Just link to the project - it's clearer that way. Especially since autokey is neither mine nor elleria's

  4. gusbemacbe commented on Oct 15, 2022

    @gusbemacbe
    Author

    @gusbemacbe it's a little bit rude to tag people in unrelated issues. Just link to the project - it's clearer that way. Especially since autokey is neither mine nor elleria's

    Ah, I'm sorry, I always sought to credit the people for the project authorship.

  5. probonopd commented on Oct 15, 2022

    @probonopd
    Member

    Espanso built for X11 will not work on Wayland due to xclip. Wayland asks for wl-copy.

    I see. So ideally the Espanso AppImage would ship both and decide at runtime which one to use.

  6. TheAssassin commented on Oct 15, 2022

    @TheAssassin
    Member

    I second building some unified AppImage that supports either system. With some scripting it should be possible to make some prototype.

  7. federico-terzi commented on Oct 17, 2022

    @federico-terzi

    Hey everyone, thanks for the feedback!

    So ideally the Espanso AppImage would ship both and decide at runtime which one to use.

    That's a really clever idea, I didn't realize it was possible. I'll investigate further, though IIRC, Espanso is not recommending AppImage on Wayland as it's not compatible with the required Linux capabilities (instead of asking the users for root access on Wayland, Espanso uses Linux capabilities to get the required permissions for a short initial period). As far as I remember from my tests, the way AppImage was structured didn't allow setting linux capabilities to the binary unless the user performed an extraction first

  8. probonopd commented on Oct 17, 2022

    @probonopd
    Member

    Thanks @federico-terzi. The contents of an AppImage are read-only, as an AppImage is a read-only self-mounting disk image. If the application was installed to e.g., /usr/bin where normal users have no root rights to change anything (and I assume normal users can't change Linux capabilities there either?), how would it work for Wayland there?

  9. TheAssassin commented on Oct 17, 2022

    @TheAssassin
    Member

    (Short overview, not 100% correct, but you'll get the idea.)

    Capabilities can be set on files to grant unprivileged processes (i.e., processes whose uid is nonzero which applies to all non-root processes) privileged access to some kernel APIs. This way, one can avoid hacks like suid and doesn't have to run an entire process as root. Since capabilities (just like suid) are stored in the filesystem metadata, they cannot be used when mounting squashfs images as a regular user. This would open all kinds of attack vectors and thus create a huge security problem. (AppImages' squashfs images are mounted with nosuid and a few similar flags for a reason.)

    There are modern alternatives to capabilities, suid etc., e.g., polkit. I've never had to work with polkit, really, though, so I'm not sure these would work for this application. I'm relatively sure I've seen AppImages use polkit before, though. See this FAQ for instance.

    @federico-terzi maybe you could elaborate a bit on why Wayland needs capabilities for regular applications? You seem to have some understanding of this. Or maybe just link to other resources? I'm curious.

  10. probonopd commented on Oct 17, 2022

    @probonopd
    Member

    Uh, is this a Linuxism that Wayland now requires? How does this work on non-Linux POSIX systems?

  11. TheAssassin commented on Oct 17, 2022

    @TheAssassin
    Member

    I don't think this may be 100% accurate. I've been running some GUI software packaged as an AppImage on a Wayland system today...

  12. probonopd commented on Oct 17, 2022

    @probonopd
    Member

    ...yes, it's not AppImage that requires this Linux capabilities thingy ;-)

  13. gusbemacbe commented on Mar 23, 2023

    @gusbemacbe
    Author

    Hello @probonopd

    I am building and testing an AppImage to make Espanso, but a small fail.

    1. I copied Debian's Espanso's X11 and Wayland to usr/bin/ of the AppImage folder, and renaming them to espanso-x11 and espanso-wayland.

    2. I wrote a pure Bash script:

      #!/bin/bash
      
      # Wayland
      if [ "$XDG_SESSION_TYPE" = "wayland" ]; then
         espanso-wayland start --unmanaged
      else
      # X11
         espanso-x11 start --unmanaged
      fi
    3. I symlinked this pure Bash script to AppRun.

    4. I updated the desktop file:

    [Desktop Entry]
    Categories = Utility;
    Comment = A cross-platform text expander written in Rust
    Exec = AppRun
    Icon = icon
    Name = Espanso
    Type = Application
    X-AppImage-Version = 78df1b7
    
    1. I ran the command appimagetool espanso-universal/ Espanso-Test.AppImage.

    I tested running it, but a small fail:

    ./Espanso-Test.AppImage 
    /tmp/.mount_EspansY2znKp/AppRun: line 8: espanso-x11: command not found
    
  14. probonopd commented on Mar 25, 2023

    @probonopd
    Member

    You need to change your script so that it loads espanso-x11 from the directory it is in, rather than from the user's current working directory (cwd).

    In other words, your script seems to want to load expanso-x11 from ./ rather than from /tmp/.mount_Espans<xxxxxx>/usr/bin/.

  15. ppvnf commented on Apr 7, 2024

    @ppvnf

    any update on this?

  16. TheAssassin commented on Apr 7, 2024

    @TheAssassin
    Member

    @ppvnf your question makes no sense. Please specify.

    That said, this is more of a question. Moving to discussions.

  17. locked and limited conversation to collaborators on Apr 7, 2024
  18. converted this issue into a discussion #1322 on Apr 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions