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
added
enhancement
|
@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? |
|
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. |
|
This issue has been open for two years, "AM" still hasn't received the attention it deserves, and AppImages are still considered second-class software packages. It makes me think that my intent to enhance AppImages failed, apparently only me cared. I'm seriously considering archiving "AM". It no longer makes sense to keep this issue open. |
|
ivan-hc: Well, I cared and recommended it when applicable. Still, for me it was a partial solution to my problem of "outliers" (i.e., apps not in repos or flatpak) because AppMan only reduced the count, and in spite of your efforts, creating my own appimages and wrappers to further close the gap was a bitch. Anyhow, a very noble effort producing slick tools, however under-appreciated. Bummer. Cheers. |
|
@joedefen thank you anyway, yours is still a good solution. The issue here is that none else care about AM or AppMan. It's what I noticed, since people prefer to care more about Flatpake and Snap. "May Appimages never have their own package manager! NO! They would be competing, and that's not nice! Let's let Snap and Flatpak monopolize software management!" This is what people and the mainstream keep think. And this is what pisses me off the more |
|
If we want stick with mainstream, we are on windows right? |
You can always request apps to be added to the database. And if it doesn't exist as appimage I might make it. appman made me stop using the Aur which is great, because even with btrfs snapshots setup, I often ran into issues that broke the entire system lol. |
Well, while on Arch, I thought AUR was a dumpster fire, and I used it as a last resort (preferring flatpaks, tarballs, etc.). But, yes, appman (had I known at the time) would have been my goto.
I have six outlier apps (i.e., crudely, self-managed apps not in repos, appman, flatpak, etc). The most widely useful, I think, would be "ventoy-gui". BTW, ventoy is available w appman, but it fails ("polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie; ==== AUTHENTICATION FAILED ===="); I've not looked into it at all .. I just uninstall appimages that don't work (and this is not the first). I'm no expert on vappman/am documentation (so pardon my ignorance), but I don't where I'd request app, where to report an appimage problem, how to share an appimage (if I ever got one working), and how to know if somebody is already working on the appimage (or declared it impractical). Anyhow, like AUR, for appman to succeed, I think, you have to harness the power of many volunteers to support it. As one idea, each time I do an "about" (or maybe an "install", too), you might provide (1) the link to the appimage's support page, and (2) a link to a page with "how to contribute" (in terms of requesting apps, signing up to implement an app, checking the status of the app (how many requests, whether in progress, whether declare impossible, etc). And to ease its "getting started", you might make, say, appman + vappman (my python tool to make it excusable) a PyPi project, so that appman is installed with "pipx install appman" rather the off-putting CLI magic. Frankly, I'd chuck AM (not self-descriptive) and make appman do both (install in common areas or home area based on whether running as root or not ... similar to pip). I don't know whether the project will get its due attention and popularity, but it seems like to me that some of the preconditions are:
Anyhow, just some brainstorming ... don't take me too seriously ... rebuttal not needed. |
I've just tested ventoy, it works here. The only way I can get that error you have is if I kill my polkit agent.
You would need to open an issue to request apps, there used to be one issue for all app requests but Ivan changed it to the user opening one instead, if you have a working appimage template that would be thru a PR adding said script to the application database. AM/AppMan has the
I think that appman should be what's installed by default instead, but that's just me, I actually mentioned this to Ivan yesterday that the INSTALL script should ask and explain which one to use. |
My duh. It did not register. I'm a i3wm noob and it has no agent and it never struck me before. I despise the polkit prompts when I have password-less sudo set up; when prompted, I just insert "sudo" in the offensive .desktop; thus, and circumventing the agent. And, yes, ventoy-gui works with sudo. But, I shoulda done this with polkit rule, in retrospect, obviously (I think that'll do it). Sorry to bother. |
I'm also a i3wm user, I actually have i3 as an appimage lol |
Sounds an awesome project.
Are you planning to make a graphical user interface?
The text was updated successfully, but these errors were encountered: