Columns and Flames in particular could benefit from this, though it wouldn't hurt in the bars views either.
I'll look into adding this the version after next, as long as there isn't huge time wasting with something else.
It actually made sense to bring this along to other visualisations when I ported the CurveView's monitor type max grouping code, so this has now been implemented. I'm going to sit on it for a week to see if anything blows up before I make an official release.
Created attachment 7506 Text appearance with scaling disabled and enabled It's been working well for the past few days (no crashes at least), however if uniform scaling is enabled (the default setting) on certain device combinations* it seems like it's writing out parts of the format string multiple times. *I had it happening when combining generic monitors with the disk read/write and network up/down devices. The graph in the screenshots has Memory and Disk-based Memory. This is happening across all graph types with text enabled. Interestingly enough toggling the setting also changes the order of the written outputs, and in the bar graphs the order the bars are drawn in.
Created attachment 7507 Screenshot of format string behavior when scale sharing is enabled
Thanks for testing :) Yes, the text overlay is output per monitor type detected in visualisation. When everything shares the one scale, the code treats everything like one monitor type, and you therefore get the original behaviour. So in your case normally you aren't using the text overlay to output data, which therefore effectively dupes the fixed string part for as many monitor types as it finds. As a crappy hack, I'll add some code to check for substitution variables - if there are none, that means the text is fixed and therefore should only be output once.
Pushed.
Alright, that makes sense I guess. I was under the impression that that's what the tags were for, but looking at it again this behavior could be useful for more easily putting pipes or newlines or whatever between types. And as a bonus, no forced colon. (Strange that memory and swap usage are considered different device types though, are the types based on which radio button is selected?) In any case, the new build seems to be working just as you said.
Tags are basically labels per monitor output, to be stuck infront of data, so that you can tell where the numbers come from. But as a user you can fiddle with it as you see fit. Yes, each radio button option represents a completely different monitor type. They all inherit from Monitor, but they are completely separate implementations.
Resolving as the new version has finally been released.