feat: Detailed Multi Core and RAM/SWAP view

[it7760]

Hey,

I stumbled over this tool and started to love it, because I wanted to read out my CPU temps on my managed device without root. But I was missing the option to view the load on each core individually. So I switched to gather all cores load individually and added the option to display them using 'd' (detailed).

This is my first contact with rust, bare with me please and happy for any feedback :)

[vladkens]

Thanks for the PR and the kind words! The feature looks appealing at first glance, but I have a concern that has kept me from adding per-core load tracking so far.

I'm not aware of any reliable, documented source that confirms how to correctly read per-core CPU utilization on Apple Silicon. Every alternative tool I've seen and reverse-engineered simply distributes load across cores in a way that looks reasonable but is essentially a guess — there's no official Apple documentation or public API backing it up.

Could you share what source or method you used to get individual core loads, and why you're confident it's accurate — especially across different macOS versions and chip generations?

[vladkens]

Thanks for the PR, and no worries about this being your first Rust contribution, I do not write Rust that much either. The code looks good overall, and I think the feature itself makes sense.

My main concern is API compatibility. The existing ecpu_usage / pcpu_usage fields are already part of the JSON/library-facing model, so changing them into per-core vectors would be a breaking change for existing users. I would prefer to keep those fields as they are and add separate per-core fields instead.

For Prometheus/Grafana, I think it is better not to expose the new per-core data yet. We can first ship and validate the feature in the TUI, and if people ask for those metrics later, we can add them separately.

One more UI note: I do not think we need a separate d key. Since v already switches views, I think it would be simpler if v just cycled through all modes, including the detailed one.

[it7760]

Thank you for your feedback!

You are of course 100% correct with your concerns about breaking the API, especially when we are relying here on undocumented/non-public Apple API. Therefor I've added the logging per core as an extra field to the JSON, so that the user can decide to ingest or ignore it, to not break any existing logging with the new feature. I've also added an experimental hint to the readme.md docs. I am still not 100% sure about the wording for the JSON fields.

On UI: I was also thinking about putting all options behind the v key, but I found it pretty annoying to toggle through all four options, especially since the detailed per core view felt to me more like an add-on than really a different view. Additionally someone can argue here, that we are (when only using v) changing the API towards the GUI user and with the d we are adding another option despite of changing an existing already known one.