I agree, a sensorpanel can be used by many more people without editing if only there were dynamic static label codes for the following items (and others I'm sure):
CPU (short like i5-6900K)
RAM (eg 96GB DDR5-4800, or short form like 96GB)
Cooling system or technology (eg DeepCool FC-120, Water Cooled, etc)
GPU (short like 7900 RTX)
VRAM (similar to RAM format)
Display (monitor name like LG Ultragear)
Storage class (like RAID 5, SSD, HDD)
As many of these values must be hand edited, this means people (especially novice users) have to dive off the deep end to find the relevant item(s) and make changes appropriate to their system. Then what they made when shared again becomes irrelevant when used by the next person with differing hardware.
I assume the software can read this information since it appears in reports. Just there seems to be a lack of useful follow-through exposing this data to people wishing to incorporate it into a dynamic sensordata (static label) design.
See my examples below. Any place where information like actual RAM/VRAM size/type are manually entered can be much more versatile if there were a static label $MYCODEHERE feature placed instead. Some like CPU and GPU have verbose static label codes that I wish could have abbreviated versions. In fact, a checkbox or selector to change the kind of fill-in data appears (totally verbose, verbose, concise eg) would be wonderful. But just having 3 codes for items that can be expressed in various lengthy or brief forms would suit - $CPUMODELSHORT, $CPUMODELMEDIUM, $CPUMODEL e.g.
UNK-RAID5.sensorpanel
