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.