Graphical User Interface - Electron

[DLopezJr]

This thread is for discussion on implementing an Electron based GUI.

The conversation started in an Github Issue: [LINK]

Topics to discuss

• JavaScript Specification and Libraries
• Developer Experience
• UI/UX Designs

[atzufuki]

I'd suggest we go for two different approaches. Actually these could be separate projects, which are just related heavily.

1. We implement a simple GUI for AM/AppMan for those who are willing to use AM as is but with a GUI. And that's it. The GUI wont have any kind of integration with existing ecosystems in the Linux world. It serves only AM users.
2. Then there is the big picture, where we are actually trying to understand the Linux world, it's ecosystems, it's users, usecases and find a way to bring appimages to wider user base. For example, it could mean that Gnome users could install AM packages via Gnome Software, KDE users could install via Discover and SteamOS/Steam Big Picture users could install via some kind of Steam plugin.

The title of this discussion currently supports the first approach. This is the easy part here. It's quite straght forward how to implement such GUI and integrate it with AM.

The hard part is the second approach. I see this as a technical and maybe contractual challenge since AM isn't actually distributing the packages, but building them on the fly. Plus AM is competing with other technologies like Snap, Flatpak and Nix. Also Toolbox/Distrobox kinda. Also it's hard to decide what part of this approach to focus on first.

[ivan-hc]

@atzufuki This

Plus AM is competing with other technologies like Snap, Flatpak and Nix

given the continuous changes that the major distributions, Fedora (with Flatpak/Wayland) and Ubuntu (Snap) have actually made "against" the adoption of AppImages, such integration is currently to be excluded. There is no interest on their part in supporting AppImages, on the contrary, for them it would be better if they died completely (and "AM" is conceived precisely because Linux is free, they cannot and must not command it).

Furthermore, we are in an era where many developers are abandoning the AppImage packaging format, partly because it is difficult to distribute/update. Also because "AM" is not widely known. Until there is adequate publicity that "there is an alternative", there will be no interest (and consequently, adoption) from developers to continue supporting AppImage.

Point 2, which you underlined, would only be possible based on the "demand" of the users, and at the moment there isn't, since (according to them) there is no method to distribute/update the AppImages (in practice they don't know our project, "AM"/AppMan).

And as you well know, the Linux user base is augmented by many new users, who would like to avoid using the terminal, which is why a UI is needed.

Today, there is a real risk that new generations of users will never know AppImage.

[zen0bit]

2. for SteamOS could be handy deckyloader