Style sort headers to look less like buttons

[MCOfficer]

• makes the button take up all available space
• replaces the default frame with some light shading
• adds an arrow indicating the sort direction

---

side note: cargo fmt (and my IDE) causes a lot of changes, if you could run those on main that'd be appreciated ;)

[FrancescoCoding]

Hey @MCOfficer, thanks for taking an interest in the project, and for the changes! The flat headers with the sort arrow look a lot better than the stock buttons.

I went through it and it all checks out.

On your side note: you are right, main had a pile of cargo fmt drift. I've formatted main and added a CI workflow that runs cargo fmt --check, cargo clippy -D warnings and the tests on every PR. To get the checks running here I merged main into your branch and pushed a small follow-up commit (you had "allow edits by maintainers" on, thanks for that). Clippy flagged the .then_some(...).unwrap_or_default() chain for the arrow text as obfuscated_if_else, so I swapped it for a plain if/else, bound the column comparison once, and made the style helper take &self. No behaviour change. Will merge once CI is green.

[MCOfficer]

Thanks for taking care of the lints.

While I'm here: For future PRs, what's your stance on using crates vs reimplementing? I already alluded to this in #4 , but after looking through the GUI code, I can think of several areas that could be improved at the expense of more dependencies. (And that you haven't done so makes me wonder if it's deliberate).

For example, catppuccin-egui could be used for styling, and one of the many table crates for the main table. And if you are open to such changes, there's no point in my beautifying the existing table ;)

[FrancescoCoding]

@MCOfficer Not deliberate, the GUI just never needed anything so far.

Crates from the egui ecosystem are fine as long as they're maintained and track egui releases. The lockfile is already ~450 crates from eframe/wgpu, so one more isn't a concern. For small Win32 stuff I'd rather write a few lines against the windows crate we already have than wrap it in another dependency, which is what I meant in #4.

For the table: yes, go for it. egui_extras::TableBuilder would be my pick since it's maintained alongside egui. It needs to keep the current row behaviour: click anywhere on the row to select, right-click context menu, selection highlight, and the sortable headers you just styled.

For the theming: I'd keep the default as native egui light/dark following the system. A theme picker with catppuccin as an option would be fine, but it's lower priority than the table for me.