Graphical user interface

[AlexTMjugador]

Is your feature request related to a problem? Please describe.
Not all users are tech-savvy enough to comfortably use the PackSquash CLI. In some cases, these users end up asking for support for relatively out-of-scope matters. In other cases, maybe they give up and stop using PackSquash altogether.

Describe the solution you'd like
A high-quality graphical user interface that is not absurdly resource-hungry or a maintenance burden that guides PackSquash users through these activities:

• Generating an options file: choosing the pack folder from the mounted filesystems, marking checkboxes to enable or disable global options, selecting directories and files to add file-specific options to them, etc.
• Saving the generated options file, or loading a previously generated one.
• Actually running the optimization process, showing its output and progress.

Describe alternatives you've considered

• Bundling an example options file and shell script to run PackSquash in the release downloads, so people can just change a few lines in a file and get things working by doing a few clicks. This sounds like a good stopgap solution that may be still useful even after PackSquash has a GUI.
• Integrating PackSquash with projects like Quiver. This has been done and it was fruitful, and I'm glad of things turned out with it. In fact, if you like fancy GUIs for pack authoring, you probably should try it out. With that said, I think it's fair that PackSquash can still be more optionally more user-friendly on its own. Also, the Quiver project may use some help with keeping the PackSquash integration updated, especially if that help comes from someone that knows more Kotlin than me.
• Improving the documentation. Of course a better documentation is always a good thing, but experience has shown that non tech-savvy users don't tend to have enough computer literacy to make use of it. They also tend to have overly broad or specific questions that are not suitable for a knowledge base. Moreover, they might be busy, or might not wish to invest more than a few minutes in understanding what is necessary to run PackSquash.
• Implementing a text-based user interface with fancy controls that guide the user through the process. I don't think this is actually much easier to do properly than a GUI (there are differing terminal sizes and capabilities, the user may change color schemes, raw mode makes it necessary to reimplement some things we get from the terminal for free, etc.), and the users that will benefit the most from a better UI won't probably care about tunneling it easily over SSH, being able to use it from text mode, or things like that.

Additional context
This has been in the roadmap for quite a bit of time, but I'm opening an issue to state my thoughts more openly and mark it as a good task for those that want to get involved with PackSquash development. The internal refactors done for v0.3.0 should make it easier to implement this elegantly, keeping high cohesion and low coupling. The following is a quote from the relevant roadmap card:

PackSquash currently does not offer a good UX to non tech-savvy users due to its CLI. Quiver can be a GUI for PackSquash (and is being used and recommended as such!), but end users may not be aware of it or may not wish to install it.

So it'd be a good idea to add a GUI for PackSquash that can be toggled on with a command line switch. A platform-specific shell script can be bundled in the download to launch PackSquash in GUI mode. It also sounds nice to bundle a configuration editor in this GUI. Relevant libraries:

• https://crates.io/crates/fltk (native, lightweight, fast, statically linked, C, but doesn't look pretty)
• Internal HTTP server + launch default web browser?
• https://crates.io/crates/conrod_core (hybrid inmediate-retained mode GUI library in pure Rust; maybe not so lightweight)
• https://crates.io/crates/web-view (the usage of IE engine by default on Windows sounds bad, although IE11 is not extremely bad. On Debian, install the libwebkit2gtk-4.0-dev package to build)
• https://crates.io/crates/sciter-rs (like Electron, but not so terribly bloated)
• tauri: not yet stable, and personally I don't like its "run this and that and it works" documentation that doesn't really explain how things work. It's also not clear whether it supports the workspace-based approach we want to use for UI frontends. I find it a bit too opinionated on how development should be for my taste
• egui: not really meant for desktop application usage. It looks like an in-game UI
• iced: yet another GUI framework for Rust that insists on either using web technologies or managing GPU rendering on its own, without noticeable benefits over something like webview
• wxWdigets: nice in concept, but it doesn't even have actively maintained Rust bindings
• qt: too big in scope and C++-focused. It has lots of custom data types and complexity for things that Rust already provides in the standard library or in crates that do one thing well. The available Rust bindings are not production ready at best
• gtk-rs: nice. In my opinion, it's the best alternative to webview for our purposes. But sadly, it brings all the GLib and GObject stack that usually makes cross-compilation and distribution harder. GTK also doesn't really look native on any platform, and it's Linux-centric (which I personally like, but those who will use the GUI the most are probably not Linux users anyway). Modern GTK, with all its CSS styling, GPU accelerated rendering and such, is probably relatively close in resource consumption to webview anyway. See: https://stackoverflow.com/questions/44736824/why-this-simple-gtk3-application-consumes-so-much-memory. My own testing on Linux with a hello world app in GTK vs. webview showed a resident process memory consumption of ~40 MiB vs. ~70 MiB, which is a very little difference even for memory constrained devices like a Raspberry Pi 3. Both flavors launched fast and have similar CPU usage and binary size (GTK is dynamically linked). On Linux there really is not much difference using GTK vs. webview, as webview relies on the GTK webview component to work, so we aren't free from the GTK stack anyway
• https://www.areweguiyet.com/#ecosystem

[AlexTMjugador]

Tauri has greatly improved since this issue was made, so it has been chosen as the GUI framework to use to carry out this task. An almost complete GUI is already implemented.