ivan-hc / AM

AppImage package manager to install, update (for real) and manage ALL of them (system-wide or locally) thanks to its ever-growing AUR-inspired database listing 2000+ portable apps and programs for GNU/Linux. The first, real centralized repository to manage your AppImages with the ease of APT and the power of PacMan.
https://portable-linux-apps.github.io
GNU General Public License v3.0
461 stars 33 forks source link

Graphical User Interface? #8

Closed Thatoo closed 2 months ago

Thatoo commented 2 years ago

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

ivan-hc commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

@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.

ivan-hc commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I will think about it...

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

ivan-hc commented 1 year ago

yad or zenity are OK for me

zen0bit commented 1 year ago

I have some experience with yad... Distrohopper

ivan-hc commented 1 year ago

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 commented 1 year ago

I will start with TUI frontend maybe...

MauricioLucas commented 10 months ago

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 commented 10 months ago

Thinking about posibilities...

yad don't fully work under wayland yet

DLopezJr commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

@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 commented 10 months ago

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

DLopezJr commented 10 months ago

@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 commented 10 months ago

@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 commented 10 months ago

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

atzufuki commented 10 months ago

@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 commented 10 months ago

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:

image

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 commented 10 months ago

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
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 commented 10 months ago

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 commented 10 months ago

@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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

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

atzufuki commented 10 months ago

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 commented 10 months ago

@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

atzufuki commented 10 months ago

Delay? I just woke up. :D

Thanks for the json. Anyway, I wouldn't mangle the description, just put it in as is. It's the UI's job to render it the way it fits the screen in a list view and show rest of the description some other way.

ivan-hc commented 10 months ago

I wouldn't mangle the description, just put it in as is

I have tried to check the validity of the json file and I had issues with lines containing double "", for example:

ivan@debian:~$ am -q '"'

 SEARCH RESULTS FOR """ IN THE LIST OF AVAILABLE PROGRAMS:

◆ adb : Android Debug Bridge (installer for "platform-tools").
◆ ark : Archiving tool for .zip/.tar/.rar and more (installs "kdeutils").
◆ armagetronad : Multiplayer game in 3d that emulates the movie "Tron".
◆ bomber : Arcade spaceship game (installs "kdegames").
◆ bovo : Five in a row game from (installs "kdegames").
◆ colorstatic-bash : CLI to generate a random colorful "Static"/"Matrix".
◆ elementary-code : AppImage version of Elementary OS "Code" by Maksym Titenko.
◆ fastboot : Tool to flash Android devices (installer for "platform-tools").
◆ filelight : View disk usage information (installs "kdeutils").
◆ granatier : Bomberman clone (installs "kdegames").
◆ kapman : Pac-Man clone (installs "kdegames").
◆ katomic : Edu. game based around molecular geometry (installs "kdegames").
◆ kblackbox : A game of hide and seek (installs "kdegames").
◆ kblocks : Classic Tetris / falling blocks game (installs "kdegames").
◆ kbounce : Fill the field game (installs "kdegames").
◆ kbreakout : Destroy bricks without losing the ball (installs "kdegames").
◆ kcalc : Scientific Calculator (installs "kdeutils").
◆ kcharselect : Character Selector (installs "kdeutils").
◆ kdf : View Disk Usage (installs "kdeutils").
◆ kdiamond : Diamond game (installs "kdegames").
◆ kfourinline : 4 in row game (installs "kdegames").
◆ kgoldrunner : A game with a runner and gold (installs "kdegames").
◆ kgpg : A GnuPG frontend (installs "kdeutils").
◆ kigo : Go strategic board game for two players (installs "kdegames").
◆ killbots : Port of the classic console game Robots (installs "kdegames").
◆ kiriki : A dice game (installs "kdegames").
◆ kjumpingcube : A game of dices on a board (installs "kdegames").
◆ klickety : Color matching like SameGame (installs "kdegames").
◆ klines : Inspired by well known game of Color Lines (installs "kdegames").
◆ kmahjongg : Mahjongg game (installs "kdegames").
◆ kmines : Classic mine game (installs "kdegames").
◆ knavalbattle : Battle Ship game (installs "kdegames").
◆ knetwalk : Net constructing game (installs "kdegames").
◆ knights : Chess interface for the KDE Platform (installs "kdegames").
◆ kolf : Mini Golf game (installs "kdegames").
◆ kollision : Dodge red balls in the field (installs "kdegames").
◆ konquest : Game of planets (installs "kdegames").
◆ kpat : Klondike, Spider, Free Cell and other Solitaire (installs "kdegames").
◆ kreversi : Reversi game (installs "kdegames").
◆ kshisen : A game similar to Mahjongg (installs "kdegames").
◆ ksirk : A strategy board game (installs "kdegames").
◆ ksnakeduel : A snake race game (installs "kdegames").
◆ kspaceduel : Battleship with satellites in the space (installs "kdegames").
◆ ksquares : Win with most number of completed squares (installs "kdegames").
◆ ksudoku : Sudoku game (installs "kdegames").
◆ ktimer : Countdown Launcher (installs "kdeutils").
◆ ktuberling : Simple Mr. Potato game for children (installs "kdegames").
◆ kubrick : A logic game based on Rubik's Cube (installs "kdegames").
◆ kwalletmanager5 : Wallet management tool (installs "kdeutils").
◆ lskat : Fun and engaging card game for two players (installs "kdegames").
◆ npm : Package manager for Node.js (installer for "node").
◆ onnx2daq : Wrapper of NNAPI ("DNNLibrary" is for "daquexian's NNAPI libs).
◆ palapeli : Jigsaw puzzle game (installs "kdegames").
◆ picmi : Single player logic-based puzzle game (installs "kdegames").
◆ stackandconquer : A challenging tower conquest board game "Mixtour" inspired.
◆ sweeper : System Cleaner (installs "kdeutils").

this is why I have removed the "" via sed

atzufuki commented 10 months ago

Double quotes should get escaped like this \". The best way to provide a JSON would be using a JSON serializer, like JSON.stringify in JavaScript and json.dumps in Python. Don't know if there is a proper equivalent for bash, but I found this with a quick search: https://jqlang.github.io/jq/.

DLopezJr commented 10 months ago

Regarding quoting, a trick I've learned is if nested quoting gets messy, it's easier to read if you use hex values. It's a lot cleaner.


$ printf '\x27\n'
'
$ awk 'BEGIN { print("\x27"); }'
'
$ echo -e '\x27'
'
ivan-hc commented 10 months ago

I've just finished to upload almost all the icons (where they were available):

@atzufuki if you need something else, let me know

EDIT: off-topic, I took advantage of this to add a check both in AM and in AppMan in case the downloaded app has no icons in the /icons directory (if the script creates it). Many bug reports refer to this, but as of today there shouldn't be any more!

atzufuki commented 10 months ago

Yes, can you publish the json as well like this maybe: https://portable-linux-apps.github.io/apps.json

ivan-hc commented 10 months ago

Yes, can you publish the json as well like this maybe: https://portable-linux-apps.github.io/apps.json

done!

ivan-hc commented 10 months ago

Today I worked on merging the AM and AppMan codes: they are now identical, apart from the first lines in the header (before the options).

As suggested by @zen0bit , the two scripts can practically be one and work as a single program.

The idea came to me after reading that @DLopezJr intends to clean up the code again by adding functions. I recently learned to write about them, in fact I have already applied a large amount of them in the ArchImage project.

Speaking of marketing, I also renewed the brand that you will find in AM and AppMan with the option -h, here it is, I hope you like it:

               _____                    _____ 
              /\    \                  /\    \         A       A
             /::\    \                /::\____\         P       M
            /::::\    \              /::::|   |          P
           /::::::\    \            /:::::|   |           M       &
          /:::/\:::\    \          /::::::|   |            A
         /:::/__\:::\    \        /:::/|::|   |             N
        /::::\   \:::\    \      /:::/ |::|   |
       /::::::\   \:::\    \    /:::/  |::|___|______
      /:::/\:::\   \:::\    \  /:::/   |::::::::\    \
     /:::/  \:::\   \:::\____\/:::/    |:::::::::\____\
     \::/    \:::\  /:::/    /\::/    / ~~~~~/:::/    /
      \/____/ \:::\/:::/    /  \/____/      /:::/    /
               \::::::/    /               /:::/    /
                \::::/    /               /:::/    /
                /:::/    /               /:::/    /╔╦╗╔═╗╔╗╔┌─┐┌─┐┌─┐┬─┐
               /:::/    /               /:::/    / ║║║╠═╣║║║├─┤│ ┬├┤ ├┬┘
              /:::/    /               /:::/    /  ╩ ╩╩ ╩╝╚╝┴ ┴└─┘└─┘┴└─
             /:::/    /╔═╗╔═╗┬  ┬┌─┐┌─┐┌┬┐┬┌─┐┌┐┌
             \::/    / ╠═╝╠═╝│  ││  ├─┤ │ ││ ││││
              \/____/  ╩  ╩  ┴─┘┴└─┘┴ ┴ ┴ ┴└─┘┘└┘   by Ivan Alex HC

  >> 𝘋𝘢𝘵𝘢𝘣𝘢𝘴𝘦 & 𝘴𝘰𝘭𝘶𝘵𝘪𝘰𝘯𝘴 𝘧𝘰𝘳 𝘢𝘭𝘭 𝘈𝘱𝘱𝘐𝘮𝘢𝘨𝘦𝘴 𝘢𝘯𝘥 𝘱𝘰𝘳𝘵𝘢𝘣𝘭𝘦 𝘢𝘱𝘱𝘴 𝘧𝘰𝘳 𝘎𝘕𝘜/𝘓𝘪𝘯𝘶𝘹 << 

PS: should I let the urls at the footer of the "help" or under the brand.

ivan-hc commented 10 months ago

PPS: I've not merget completelly the two projects because each of them can be installed differently. However, I'll still do some tests before releasing the version 5 of AM.

ivan-hc commented 10 months ago

4:30 a.m. here in Italy, and I've just finished to merge AM and AppMan. Now their code is the same, so you have no more to choose between the two.

Just one detail made them different:

So let's keep this standard: "am" as a symlink in /usr/local/bin for /opt/am/APP-MANAGER and "appman" as "appman", always, otherwise what I try to make simpler will be more... confusing! xD

DLopezJr commented 10 months ago

@atzufuki I have made the discussion thread for GUI discussions regarding an Electron design. [LINK]

@ivan-hc Very glad to hear you merged AM and AppMan. That will makes this codebase a lot easier to comprehend. Great to hear you're familiar with functions now! I've made a discussion thread for refactoring the codebase so we can discuss things out and stay in sync. [LINK]

ivan-hc commented 8 months ago

In the latest version 5.6.3 I have removed less -E from the install option. I don't know if this would be helpful for a UI. I know that using less may be an obstacle sometime, expecially if you want to see the output.

Also I have restored the old name of the repository, from "AM-Application-Manager" to "AM", as in the earlier days of this project, when I started to wrote it, according with this github feature. I think it is easier now to remember and search (for example by googleing "am appimage").

On https://portable-linux-apps.github.io I have added all the icons for all 1871 items listed.

To resume other improvements since first half december, a better -f option interface, support for custom repositories, you can add a github personal APIkey, a test option to instll your own script created with -t... right now I don't remember other things I've done.

Is there anything I should do now to easier your work? I hope this project hasn't tired you. I'm doing everything I can to improve it.

ivan-hc commented 7 months ago

For those who missed the latest updates, thanks to @nazdridoy suggestions, AM is no longer a monolithic script, but a modular one: 27 scripts each dedicated to an option or two (see https://github.com/ivan-hc/AM/tree/main/modules), all managed by APP-MANAGER. Update to version 6 of AM or AppMan to see the changes.

https://github.com/ivan-hc/AM/assets/88724353/38f0ccd0-93ac-454a-925d-0997dde77245

EDIT: for the more curious, in the background, I'm working on the implementation of 32bit libraries in the Steam AppImage. If you want to help me, this is the link https://github.com/ivan-hc/Steam-appimage

ivan-hc commented 7 months ago

Update: today we exceeded 1900 installation scripts for x86_64 (right now there are 1919).

Is there any news?

@atzufuki

atzufuki commented 7 months ago

Is there any news?

@atzufuki

Not at the moment. I have been busy at work and with my own business. But I now activated in the discussion and will continue the conversation there.

zen0bit commented 7 months ago

Thinking about posibilities...

yad don't fully work under wayland yet

EasybashGui have some updates, so will try next..

zen0bit commented 7 months ago

TUI #175

zen0bit commented 7 months ago

It would be nice to separate all UI calls in AM to default UI module. so can be easily interchangeable. And all potential GUI and TUI could be just modules ❤️

zen0bit commented 6 months ago

Thinking about posibilities...

yad don't fully work under wayland yet

EasybashGui have some updates, so will try next..

Looks like easybashgui is best option

Easy Bash Gui shortened as EBG, is a Posix compliant Bash functions library that aims to give unified GUI functions using frontends for dialogs boxeds (from the user's point of view are frontends but from the EGB side are backends) Backends environments GUI

EBG implements different dialogs boxes! You don't have to worry about what environment you are running the script in, as EasyBashGUI will handle this transparently, based on the availability of the backends (frontends).

Console mode:

Heus-Sueh commented 6 months ago

my recommendation for which GUI to use, I think Toga or QT are better candidates than tkinter or fltk, these libraries are simple and light, but they are not modern and nowadays not many people are interested in learning them as there are better alternatives.