Skip to content
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

Refactor widget system #374

Open
4 tasks
ClementTsang opened this issue Dec 23, 2020 · 0 comments
Open
4 tasks

Refactor widget system #374

ClementTsang opened this issue Dec 23, 2020 · 0 comments
Assignees
Labels
refactor For refactoring issues. Generally you won't need to use this tag in your report.
Projects

Comments

@ClementTsang
Copy link
Owner

ClementTsang commented Dec 23, 2020

There are some things that need to be refactored. The code has grown in a rather messy way, making it get a bit harder to further develop, and I would rather do it now rather than later.

My main issue is that adding new GUI elements is absolutely awful right now. Like, when I originally planning on adding the in-app config system, the thought of doing that made me abandon ship since it would take too long for the initial 0.5.0 release.

  • State management is an absolute mess with this current system. We use basically one single source of "state" - the App struct - and use that to mass-manage everything. This works, but the problem is that management of a widget's state - like scrolling, or clicking - is completely handled by the app struct! Meanwhile, all the drawing implementations for the widget are handled elsewhere, in a completely different area. This leads to a very disconnected method of development.
  • A ton of code duplication and manual boilerplate. For example, across the 3 table widgets (process, disk, temp), there's barely anything shared, even though they're basically the same thing.
  • The current way some things are written make expansion absolutely painful. For example, adding a new column for the process widget is kinda annoying with the intrinsic column calculation method, but it's even more annoying when you consider optional columns that might be hidden at will in the future, since most of the information is currently stored in a disjointed way that makes it hard to work with.

Current goals

  • Redo widget, state, and input handling system. Currently planning on separating this out first as it's the biggest annoyance for me, and would make adding GUI-related changes a bit easier.
    • Introduce a new system (maybe as a separate crate?) to help pre-define a widget system that can handle their own state and user inputs. For example, I should be able to add a scrollable table widget that can handle it's own scroll state, and have modifiable actions for drawing and things like clicking/scrolling (but with sane defaults).
    • For tables, tie columns and widths together.
    • Use a universal method of row input. Remember to store information like optional/shrinkable info.

Ideally in the future, I would also like to do some general rearrangement of code file and responsibility structure. This is less important for now but would be nice to get to as soon as possible, as I also really, really don't like how the project is structured in terms of organization. Like, many parts of it could clearly be restructured to be easier for me (and others) to work with. I can probably do this as another problem later.

@ClementTsang ClementTsang created this issue from a note in 0.6.0 (In progress) Dec 23, 2020
@ClementTsang ClementTsang added the refactor For refactoring issues. Generally you won't need to use this tag in your report. label Dec 23, 2020
@ClementTsang ClementTsang self-assigned this Dec 23, 2020
@ClementTsang ClementTsang changed the title Mass refactor of code Refactor widget system Dec 23, 2020
@ClementTsang ClementTsang removed this from In progress in 0.6.0 Feb 15, 2021
@ClementTsang ClementTsang pinned this issue Jun 26, 2021
@ClementTsang ClementTsang added this to In Progress in Next Oct 11, 2021
@ClementTsang ClementTsang mentioned this issue Jun 19, 2022
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor For refactoring issues. Generally you won't need to use this tag in your report.
Projects
No open projects
Next
  
In Progress
Status: In Progress
Development

Successfully merging a pull request may close this issue.

1 participant