ChrisTitusTech
Start working on GUI for this tool.
- Start working on the GUI for this utility
- Comment out sidebar (will probably remove it) and start working on layout similar to winutil
Pull Request
Title
Type of Change
- [x] New feature
- [x] UI/UX improvement
Description
I am working on GUI that can be used on desktop distributions (e.g. Fedora), which functions similarly to the GUI that's being used to for Winutil. I am doing this, because I just want to have this utility as a desktop application.
Testing
I've performed a build and run test (running cargo run) to check that everything compiles. The eframe library doesn't require any external dependencies, so you can just build it.
Impact
There are introduced two new dependencies to the codebase: eframe and egui_extras. The first one is the UI framework that is used to make the graphical version of this program and the second one is the crate used to make Grid.
Issue related to PR
- Resolves #236
Additional Information
The utility has a match arm on the beginning that checks for the $DISPLAY environment variable.
Checklist
- [x] My code adheres to the coding and style guidelines of the project.
- [x] I have performed a self-review of my own code.
- [x] I have commented my code, particularly in hard-to-understand areas.
- [x] I have made corresponding changes to the documentation.
- [x] My changes generate no errors/warnings/merge conflicts.
P.S.: The lines changed are 60, GitHub counts the lines in Cargo.lock file.
Linutil is in very early stages, a GUI may be better postponed for after it reaches relative stability. Major changes almost certainly will still be made to the codebase, and any extra UI would have to be adapted to them.
If a GUI is to be added, the structure of the project should be changed. We should move independent components (e.g. tabs/entries) to their own crate, and then make separate TUI and GUI crates which only contain the logic to build said UI. Building both a TUI and GUI into one binary doesn't make a whole lot of sense, especially if you're only going to display the TUI in a TTY. Most people are likely only going to be able to make use of one or the other; binary bloat should be avoided and of course adding dependencies increases build time and exposure to potential security risks.
More discussion should also be had on which GUI library or framework should be used. There are several reasonable options, and the project maintainer really should be the one who makes this decision. If more people contributing are familiar with web development, perhaps Tauri would be a better option. Or, for a more mature library, gtk-rs could be used, or iced, which is being heavily developed, especially with System76 choosing it for libcosmic.
This is why this PR is still a draft. I chose egui because I am most familiar with it.
Note: the command execution isn't working yet, because it is relying on function used to run scripts in TUI.
It is egui, a Rust native GUI. It doesn't require any external dependencies, so it is used here.
Linutil is in very early stages, a GUI may be better postponed for after it reaches relative stability. Major changes almost certainly will still be made to the codebase, and any extra UI would have to be adapted to them.
Then guard it with a features flag.
Sorry for the inconvenience. We had a massive restructure of the codebase to improve future development. Because of this can you update your PR to the new structure. Thank you for your assistance and contribution.
