Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Feature idea: Alternate way to get sensor information
#1
The biggest problem with the HWiNFO plugin as it currently stands is ease of use. A user is required to go through a long list of sensors to find what they want, and manually input sensor IDs into a skin file. Especially with large skin suites, this can be quite daunting and can turn away many a user of that suite because they don't understand how to do it properly.

To alleviate this issue, I propose that an additional ability be added to the HWiNFO plugin: Gathering information about a sensor based on its position in the list of sensors. For example, if 'Virtual Memory Committed' (under the 'System' group) is the first item on the list in the SMV, its index number would be 1. The next one, 'Virtual Memory Available' would have an index number of 2. And so on.

Since the index values would be drastically different on each PC, using that measure directly in a skin would not be practical and would not solve the overarching problem of ease-of-use. Instead, this ability could be harnessed by an LUA script to construct a table, containing all the sensors in the SMV, and all their information (including the sensor ID, sensor instance, and entry ID). Then, it could parse every sensor name and entry name, picking up common keywords like 'CPU' or 'Memory' and being able to determine what that sensor is based on its names. Then, the script could gather the hexadecimal values from this entry and assign them to the corresponding variables in the skin.

That's a very specific usecase, but it would almost completely solve our problem. There would likely be a few things it can't figure out or a few things it misidentifies, but it would still narrow user interaction with configuring the plugin from every needed sensor to just a few of them. I believe this feature could greatly expand the popularity of HWiNFO-based skins, and alleviate many headaches caused by them.

Also, why does it use hexadecimal identifiers anyway? The Samurize plugin uses regular integers, which are much easier to work with and configure than hexadecimal values. Could that possibly be changed as well?

Great job on the plugin so far! I'll answer any questions that come up. Thanks for reading!
Reply
#2
Your proposed solution to use indexes in the list of sensors found would not work well in some cases when new sensors or values can appear or disappear (i.e. user adds a new drive, GPU, etc.). Also it's likely that new updates to HWiNFO add new sensors or values in the middle of the list.
Also creating a list of all possible sensor values would be very difficult as there can be many instances of the same sensor (like multiple CPUs, GPU, drives) and there is a huge amount of different values possible which is very likely to change over time. For some sensors it's also not possible to know what values are possible in advance - i.e. some sensors don't have a fixed type of values returned, they rather just return a name of sensor.
I was already planning to somehow generalize and unify all the sensor values returned, however this would be quite difficult to implement for some sensors and also might cause certain limitations to flexibility.
Reply
#3
Smile 
(04-10-2016, 10:08 AM)Martin Wrote: Your proposed solution to use indexes in the list of sensors found would not work well in some cases when new sensors or values can appear or disappear (i.e. user adds a new drive, GPU, etc.). Also it's likely that new updates to HWiNFO add new sensors or values in the middle of the list.
Also creating a list of all possible sensor values would be very difficult as there can be many instances of the same sensor (like multiple CPUs, GPU, drives) and there is a huge amount of different values possible which is very likely to change over time. For some sensors it's also not possible to know what values are possible in advance - i.e. some sensors don't have a fixed type of values returned, they rather just return a name of sensor.
I was already planning to somehow generalize and unify all the sensor values returned, however this would be quite difficult to implement for some sensors and also might cause certain limitations to flexibility.

Well, as long as you're working to simplify it, I'm happy. Thanks for your time. Smile
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)