Graphical User Interface?

[Thatoo]

Sounds an awesome project. Are you planning to make a graphical user interface?

[ivan-hc]

Thank you, it would be great but I've not much time to study a new language (for job's reasons). I'm working alone on this project and there are still a lot of things to do, for example to convert the scripts of appimages built using pkg2appimage or other compilers to complete appimages built trough github-actions, to prevent big download of datas and too CPU usage during the process (see 0ad, VLC, GIMP, Abiword...). A GUI based on AM would be great, but seems that this project is no more an interesting one like before. However I've provided the base... I only need some help or someone that works in parallel on this base to improve the project with me. This is an appeal that I launched from the very beginning, when there were fewer than 100 apps managed (now there are 1350 apps), but I'm still alone. I've completed the scripts for x86_64 only because this is the only architecture I use normally, but this script can manage any app on any architecture... I only need help to improve the project.

[Thatoo]

I'll check on pkg2appimage to see if I can be of any help. Otherwise, how can we make a GUI? What tool could help?

[DLopezJr]

@ivan-hc Do you know python? Enough people know it, so should be able to find some help.

I would suggest looking into tkinter or PySide.

• https://docs.python.org/3/library/tkinter.html
• https://wiki.qt.io/Qt_for_Python

[ivan-hc]

Do you know python?

@DLopezJr honestly, I don't like it much. I was thinking about something based on QT or GTK. However any client can use both AM an AppMan as an inbuilt engine, so any GUI is OK for me.

[DLopezJr]

If you want to use QT, maybe checkout QT Designer. [LINK]

It's a drag and drop editor for QT. It can give you the output code in C++ or Python.

[ivan-hc]

I added raw view of installation scripts for x86_64 at https://portable-linux-apps.github.io/apps.html

This would be helpful if you're interested to an Electron-based client.

PS: any news? Is there someone interested to a GUI frontend?

[zen0bit]

I will think about it...

But nothing to fancy, I am not programmer so maybe in yad...

[ivan-hc]

yad or zenity are OK for me

[zen0bit]

I have some experience with yad... Distrohopper

[ivan-hc]

This would be a GUI fronted, using the new option --user of AM allows users to use AM the same way you use AppMan, so users of AM can decide to switch AM to a non-privileged use, exactly the way you do with AppMan

[zen0bit]

I will start with TUI frontend maybe...

[MauricioLucas]

• Sorry if my comment is redundant, I'm traveling and I only just realized that this was already mentioned

I believe that YAD is the most elegant front-end for all types of scripts in the unix world.

The code can be assembled to offer the test version facilities with YAD without interfering with the current "AM" code as it would only trigger the commands that are already displayed in graphical mode.

Some links that will help you realize its potential: Website with best examples: yad-guide.ingk.se/ Official Link: github.com/v1cont/yad Old Link samples: sourceforge.net/p/yad-dialog/wiki/browse_pages/ Discussion Group: groups.google.com/g/yad-common

[zen0bit]

Thinking about posibilities...

• [ ] yad GUI
• [ ] gum TUI
• [ ] easybashgui TUI/GUI
• [ ] other??

yad don't fully work under wayland yet

[DLopezJr]

You can check out tcl/tk (very simple to use) or FLTK (C++ but simple and small).

EDIT: There also is Dear ImGui which has bindings I believe to a couple of languages.

[atzufuki]

I think there might be room for several GUI's for different user groups. For example an integration to Gnome Software would be a no-brainer for Gnome users.

I'm a web dev myself and enthusiastic about pure vanilla web components. Therefore I could work on an Electron based app.

This project isn't too popular, nor AppImages in general. Therefore I'm thinking ahead, like what user group we should prioritize and what kind of design the app should have in terms of marketing. There is now some hype around Steam Deck, SteamOS and gaming on Linux in general. And they are really lacking a reliable way to install non-steam apps. So maybe we should target this area to boost this project? Therefore the Electron app should integrate well with Steam's ecosystem in terms of design and UX.

[ivan-hc]

@atzufuki I've actually always thought of Electron as a solution, precisely for all the reasons you explained. Electron offers greater cross-platform compatibility. I've seen that some projects (including Bottles) are starting to move towards that technology specifically to export their projects to multiple different platforms.

Unfortunately I am not good at any type of coding other than SHELL, so I trust in your more expert hands.

[atzufuki]

Awesome. I shall look for time to implement a first working version soon.

[DLopezJr]

@atzufuki and whoever else works on the electron version,

Is there any chance you can keep it to VanillaJS? Would be easier for future contributors if they didn't need to learn another layer of software (eg. React, Typescript, npm, Vue, etc)

[atzufuki]

@DLopezJr Depends on what you consider vanilla exactly. Every code base is different and there is no universal way of doing things, hence we need some way to teach the basics specific to this project to new developers anyway. It's possible to achieve really maintainable and really unmaintainable code bases regardless the technology stack, although a bigger stack usually means the latter.

To me these frameworks like React and Vue bring nothing and they solve nothing. They just complicate things with magic and just like you mentioned, there will be a higher learning curve for any developer. I think there isn't a single problem they solve, which couldn't be solved via native API's. Nowadays it's even possible to implement reusable components using native custom elements API, which was one of the biggest marketing point for React back in the day.

So, I can promise to go as vanilla as possible but I will also promise maintainability. To be able to provide that maintainability, there will be some decisions made on top of vanilla. Again, depending on what you consider vanilla.

NPM is pretty much a must at this point, I don't think there is any other way. I would use TypeScript, since the benefit is so much bigger than the learning curve, especially for new developers who might not know TypeScript beforehand.

[Thatoo]

A good alternative to Electron is https://tauri.app/ in case you plan to check for alternatives.

[atzufuki]

@Thatoo Tauri is great but it uses WebKit on Linux and personally I've had a hard time working with WebKit on Linux. Maybe it's just me but WebKit feels still quite unpolished while encountering very weird problems even with the most basic tasks. It's funny because at the same time I'm a fan of WebKit. :D

Well, it should be easy to port from Electron to Tauri in the future if WebKit matures up ja Tauri becomes the next industry standard. At least if you know Rust.

[atzufuki]

I started tinkering with Electron for couple of hours and installing a package by clicking a button is now technically working while using AppMan at the moment. :clap: :clap:

For me it parses the app list from ~/Applications/appman/x86_64-apps which gets updated on launch by appman list. This isn't the best way to integrate the UI, since that app list is meant for representation in terminal, not for application communication. But it works for simple listing purposes if the format remains the same.

For more diverse purposes like displaying icons we need more backend stuff. Since getting icons automatically isn't trivial, I think we should start maintaining icons manually in Github alongside name and description. Other solution could be having a real online backend with a database and file hosting, which both the GUI and CLI depends on.

About the direction and goals of the project, if we were building not just a GUI for an application manager, but a full fledged application store like Gnome Software with commenting and reviewing, then we would really need that real online backend and a database, therefore a sponsorship/funding. That said I think there is bunch of decisions to be made about the direction of the project, which I think is the hardest part. Like how to break the market in the current ecosystem without wasting time and effort.

[ivan-hc]

This is a dream that become true!

To get the icons should not be a problem.

If you're able to get each line as a group of items, for example by replacing ":" with a new line, we should be able to have something like this:

avidemux	kdenlive
Multiplatform Video Editor.	A powerful Video Editor provided by KDE.
install	install

To generate that kind of list (and the home page) I use a script on my PC that you can get from here: https://github.com/ivan-hc/AM-Application-Manager/blob/main/tools/am2pla-site

Due to github API limits that allow you to connect and download stuff via CLI only some dozens of times per hour, to download and generate the icons would be a problem if done manually, but we can implement something like this in github actions and start downloading an archive with all the icons we need, each of them in a separate directory into a Tar archive, and all we must do is to upload it. All new addition istead would be done manually.

I want to start a test for this.

[ivan-hc]

I started adding icons on https://portable-linux-apps.github.io/apps.html

For now I have uploaded 1/3 of all the icons (641 vs the 1839 to add)

[DLopezJr]

@atzufuki

Thank you for your work getting a UI proof of concept up and running.

I like your mindset, on expanding appimages from a marketing standpoint. @ivan-hc has done a tremendous job on this project and with your help on Ui and marketing tactics I do see potential with the project.

We should probably move this discussion out of issues and into discussions. I'll respond to you here, but I think we should move the conversation to over there. We can strategize there in depth on how to grow out the project.

Depends on what you consider vanilla exactly. Every code base is different and there is no universal way of doing things, hence we need some way to teach the basics specific to this project to new developers anyway. It's possible to achieve really maintainable and really unmaintainable code bases regardless the technology stack, although a bigger stack usually means the latter.

Excellent points. There is no official definition for "Vanilla JS", so a better spec to follow would probably be the most commonly used ECMAScript version at the time of development.

So, I can promise to go as vanilla as possible but I will also promise maintainability. To be able to provide that maintainability, there will be some decisions made on top of vanilla. Again, depending on what you consider vanilla.

I respect all of that. That sounds ideal.

NPM is pretty much a must at this point, I don't think there is any other way. I would use TypeScript, since the benefit is so much bigger than the learning curve, especially for new developers who might not know TypeScript beforehand.

It seems difficult to use TypeScript without npm. Would love to discuss your ideas more in a discussion to even learn for my own sake. I think as we list out the requirement for the UI, it'll steer things into the right direction.

For example, since AppImages are self-contained files unlike flatpaks, a user could technically just use the site to download the AppImages. That's what AppImageHub. If a plan is laid out that the site and electron app can use, this could effectively be killing two birds with one stone.

My main contribution to this project has been refactoring the 'APP-MANAGER' file for readability. My main goal of 2024 will be stage two of that refactor (breaking the script down into functions) but I am free to help with easing the developer experience/deployment of the UI.

[atzufuki]

@DLopezJr Thank you for your insight. I believe this project could really help AppImages to become a major packaging candidate in the Linux world if the cards were played correctly. Sure, let's move this conversation to discussions.

For example, since AppImages are self-contained files unlike flatpaks, a user could technically just use the site to download the AppImages. That's what AppImageHub. If a plan is laid out that the site and electron app can use, this could effectively be killing two birds with one stone.

Hmm, but it's gonna be a little more complicated since we can't host pre-built AppImages, but their packaging scripts. Maybe the user could download the packaging script, it would launch a simple prompt asking for both packaging and installation to be done, just like AppImageLauncher does? That said, maybe AppImageLauncher should support running scripts (the packaging script) before the install/integration process?

[atzufuki]

To generate that kind of list (and the home page) I use a script on my PC that you can get from here: https://github.com/ivan-hc/AM-Application-Manager/blob/main/tools/am2pla-site

Of course you have a script for that. :) Maybe create a script to provide a JSON version, so it would be easy to parse?

[ivan-hc]

If you give me the scheme of the json file you need I can try to do something like am2pla-site in SHELL

[atzufuki]

If you give me the scheme of the json file you need I can try to do something like am2pla-site in SHELL

I'd go with this if some day we need some additional metadata or something, like version idk.

{
  // "version": "1",
  "apps": [
    {
      "packageName": "0ad",
      "description": "FOSS historical Real Time Strategy (RTS) game of ancient warfare...",
      "icon": "https://portable-linux-apps.github.io/icons/0ad.png"
    },
    {
      "packageName": "0ad-latest",
      "description": "Real Time Strategy game of ancient warfare (development branch)...",
      "icon": "https://portable-linux-apps.github.io/icons/0ad-latest.png"
    },
    {
      "packageName": "3d-puzzles",
      "description": "3D-Puzzles are Rubik, Dogic and Dogic12...",
      "icon": "https://portable-linux-apps.github.io/icons/3d-puzzles.png"
    }
  ]
}

or just

[
  {
    "packageName": "0ad",
    "description": "FOSS historical Real Time Strategy (RTS) game of ancient warfare...",
    "icon": "https://portable-linux-apps.github.io/icons/0ad.png"
  },
  {
    "packageName": "0ad-latest",
    "description": "Real Time Strategy game of ancient warfare (development branch)...",
    "icon": "https://portable-linux-apps.github.io/icons/0ad-latest.png"
  },
  {
    "packageName": "3d-puzzles",
    "description": "3D-Puzzles are Rubik, Dogic and Dogic12...",
    "icon": "https://portable-linux-apps.github.io/icons/3d-puzzles.png"
  }
]

[ivan-hc]

@atzufuki sorry for the delay, I was a bit busy.

This is based on am2pla-site, made it executable and wait until the apps.json fie is ready:

#!/usr/bin/env bash

# THIS SCRIPT IS NEEDED TO GENERATE A JSON FILE OF ALL APPLICATIONS WITH EASE
cd $(xdg-user-dir DESKTOP)
AMREPO="https://raw.githubusercontent.com/ivan-hc/AM-application-manager/main"
arch="x86_64"
echo "" >> args
wget -q $AMREPO/programs/$arch-apps && echo -e "$(cat ./$arch-apps | awk -v FS="(◆ | : )" '{print $2}')" >> args
echo STOP >> args
ARGS=$(sed '1d' ./args)
echo "[" >> apps.json
# THIS IS THE WORKFLOW
for arg in $ARGS; do
	for var in $arg; do
	if [ $arg == STOP ]; then
		break
	else
	case $arg in
	am) ;;
	appman) ;;
	*) for var in $arg;
		do
		description=$(cat $arch-apps | grep "◆ $arg :" | sed 's/"//g' | sed 's/^.*: //')
		echo -e '  {\n    "packageName": "'$arg'",\n    "description": "'$description'..",\n    "icon": "https://portable-linux-apps.github.io/icons/'$arg'.png"\n  },' >> apps.json
		sleep 0.005
		done;;
	esac
	fi
done
done
sed -i '$s/,$//' apps.json
echo -e "]" >> apps.json
rm ./args ./$arch-apps

This is the file I've generated with this script:

apps.json