Yup, the whole reason this was brought up in the first place. And how the demo skin is layed out too. I imagine this support is a pain for skin devs distributing and needing to support (and receive negative feedback cause it doesn't work).

stangowner wrote:Yup, the whole reason this was brought up in the first place. And how the demo skin is layed out too. I imagine this support is a pain for skin devs distributing and needing to support (and receive negative feedback cause it doesn't work).

Yeah, although I think the net result is some reluctance to include a "sensors" skin in the stuff they distribute. If they do, then they have to clearly document (not trivial) exactly how each user needs to change things to work with their system.

I'm still not convinced there is much that can be done about it. To really have an impact on ease-of-use, I personally think that there would need to be some standard set of sensors defined that are pretty much on all machines. They all have a CPU right? Then reverse the process for that subset of the sensors. Allow for it to be asked for by a standard "name" like CPUCore0Temp or whatever, and the plugin itself "figures out" what sensor that is and how to access it. If that were possible, that might work for, I don't know, 80% of common computer systems, while still allowing a full-blown definition using the current approach for sensors that aren't as common.

I think as long as the user has to define the sensor and its components by hexadecimal numbers that specifically point to the sensor, this just has to be complicated. I'm not really complaining, It might just be how it is...

jsmorley wrote:Yeah, although I think the net result is some reluctance to include a "sensors" skin in the stuff they distribute. If they do, then they have to clearly document (not trivial) exactly how each user needs to change things to work with their system.

I'm still not convinced there is much that can be done about it. To really have an impact on ease-of-use, I personally think that there would need to be some standard set of sensors defined that are pretty much on all machines. They all have a CPU right? Then reverse the process for that subset of the sensors. Allow for it to be asked for by a standard "name" like CPUCore0Temp or whatever, and the plugin itself "figures out" what sensor that is and how to access it. If that were possible, that might work for, I don't know, 80% of common computer systems, while still allowing a full-blown definition using the current approach for sensors that aren't as common.

Yup. I'm discussing with Martin now. But we had this discussion a few years ago. You may be right, that it is what it is. Even a small standard list of reading is not trivial once you add users to the equation....haha.

I think that Martin’s alternate solution has some merit. It would be possible to create an interface where you choose the variable(s), then choose the sensor and entry from the SMV list. The program would then write the correct values to the .INC file based on the user’s selection.

stangowner wrote:Yup. I'm discussing with Martin now. But we had this discussion a few years ago. You may be right, that it is what it is. Even a small standard list of reading is not trivial once you add users to the equation....haha.

Well having a way to "output" a complete list of sensor identification numbers to a .inc file that can be opened and browsed through to "copy and paste" needed information might be marginally easier than having the user open the SharedMemoryViewer app and copy and paste from that I suppose. It does kinda remove one "step" for the user if the skin can designed to create the .inc file the first time it is run or on demand, and then pop open the .inc file in a text editor or something.

It's all just nibbling around the edges of a process that is going to be painful, especially for a new user, and I doubt much can be done.

raiguard wrote:I think that Martin’s alternate solution has some merit. It would be possible to create an interface where you choose the variable(s), then choose the sensor and entry from the SMV list. The program would then write the correct values to the .INC file based on the user’s selection.

I think I have a solution that will be slightly more of a pain for skin authors, but significantly easier for the average user.

The SMV interface will expand to include a list. Skin authors will use a file in the same directory as the SMV, called something like "HWiNFOConfig.json" (JSON is the only format I can think of that will do the job, but it doesn't necessarily need to be JSON). In this file, the author will create a table structured like so:

Each "page" will be a different skin (ie. CPU Meter, GPU Meter, etc.). Within each page will be various groups or standalone entries. Each "entry" corresponds to a measure or set of variables that will be set, defined in the "entry details" portion of the file. The entry details will act like a !WriteKeyValue, in that you specify a section

To use the tool, you pick an entry (such as "Core 0 Temperature" under the "CPU Temperatures" group) from the list. It will show the currently bound entry in the SMV list portion. You can click an edit button, and choose a different entry from the list. When you click save, it will write the details of that entry as specified in the entry details to the file.

Here is a small example (pardon my formatting - I'm not too well-versed in how to write JSON files):

Each entry will have a label name, and the section that it will write to (whether that be variables or a measure). The next arguments are all the parameters from the SMV window.

The purpose of the external table is to let skin authors tailor the SMV configuration to their own skins as desired. This way, users will be able to simply go down the list and be sure all of the values are tied to the correct entries in the SMV table.

The only thing I haven't figured out it is where/how to tell the program which file it needs to write to. You can't use Rainmeter variables, so perhaps it would be a relative path from the root config path?

I hope I explained that adequately, if not I apologize. I also have no knowledge whatsoever in writing Windows programs (my only programming experience is with Rainmeter and a year of Java in Computer Science class), so I don't know the limitations of the software.