-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Graphical User Interface? #8
Comments
Thank you, it would be great but I've not much time to study a new language (for job's reasons). |
I'll check on pkg2appimage to see if I can be of any help. |
@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. |
@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. |
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. |
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? |
I will think about it... But nothing to fancy, I am not programmer so maybe in yad... |
yad or zenity are OK for me |
I have some experience with yad... |
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 |
I will start with TUI frontend maybe... |
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: |
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. |
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. |
@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. |
Awesome. I shall look for time to implement a first working version soon. |
@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) |
@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. |
A good alternative to Electron is https://tauri.app/ in case you plan to check for alternatives. |
@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. |
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. 👏 👏 For me it parses the app list from 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. |
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:
To generate that kind of list (and the home page) I use a script on my PC that you can get from here: 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. |
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) |
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.
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.
I respect all of that. That sounds ideal.
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. |
@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.
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? |
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.
|
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! |
Yes, can you publish the json as well like this maybe: https://portable-linux-apps.github.io/apps.json |
done! |
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
PS: should I let the urls at the footer of the "help" or under the brand. |
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. |
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 |
@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] |
In the latest version 5.6.3 I have removed 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 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. |
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. simplescreenrecorder-2024-02-15_18.11.19.mp4EDIT: 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 |
Update: today we exceeded 1900 installation scripts for x86_64 (right now there are 1919). Is there any news? |
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. |
TUI #175 |
It would be nice to separate all UI calls in AM to default UI module. so can be easily interchangeable. |
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) 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 Excited to see your pull request using Toga or Qt :) |
sorry man, I was just recommending it, I won't be able to implement it because I'm new to programming |
@Heus-Sueh don't worry |
I mention AM to nitrux development team. |
Godot engine? 🤔 |
@zen0bit Unless you find a dedicated Godot or two developer that's a risk that is not worth taking. |
Any knowledge gained will satisfy me, and open new opportunities... |
hey GUIys 🤣 would you like to see what I've found on the antix forum? An ui for AppMan https://www.antixforum.com/forums/topic/appman-a-package-manager-for-appimage-and-binary-files/ download from here https://www.antixforum.com/wp-content/uploads/2023/06/appman-gui-5.1.zip this is genial in my opinion PS: we have this issue opened from two years and the only one that have done a (partial) GTK GUI to solve this issue have not joined us. Its a shame. |
Maybe I can learn a bit from them |
Hey all interested in a GUI interface (like I was). Since a GUI seems to be long-term project, I wrote a quickie, python-curses based layer atop appman called I think it provides much of the potential value of a GUI app at (obviously) a fraction of the development cost (and maintenance). Thus, it might have some wider interest as a replacement for the GUI or, at least, a temporary project.
I'm happy with Cheers. |
Sounds an awesome project.
Are you planning to make a graphical user interface?
The text was updated successfully, but these errors were encountered: