stangowner wrote:Thoughts? This would allow you to have specific buttons to launch portions of the config for the user, or just launch them all at once. But the sensors won't be a skin heirarchy, just split by tab (inc file).

I like this idea. One very minor suggestion I have, since the Rainmeter devs have a philosophy of maintaining backward compatibility, is that passing no arguments on the command-line should result in legacy behavior (i.e., no tabs, etc.). That way an older skin that expects the previous behavior (i.e., does not have the new INI file format with the [HWiNFO-Config] section) won't suddenly have unexpected behavior if someone updates the plugin to the new version.

SilverAzide wrote:I like this idea. One very minor suggestion I have, since the Rainmeter devs have a philosophy of maintaining backward compatibility, is that passing no arguments on the command-line should result in legacy behavior (i.e., no tabs, etc.). That way an older skin that expects the previous behavior (i.e., does not have the new INI file format with the [HWiNFO-Config] section) won't suddenly have unexpected behavior if someone updates the plugin to the new version.

In the case of HWiNFO, I'm not too concerned about backwards compatibility with the plugin, I think that upgrading the plugin can require a change to skins, and that's fair. If upgrading the HWiNFO application in and of itself breaks existing skins, that would be very unfortunate.

Actually, compatibility is not an issue for this change at all. The only change here is the "helper" app (shared memory viewer) that users currently use to update their skin variables manually (a requirement for the plugin). There is no change to HWiNFO, the plugin, or the behavior of the plugin & skin.

So basically, new skins moving forward could create this new [HWiNFO-Config] section, follow the variable naming convention, and therefore give the users of the skin a "friendlier & easier" way to update their variables. Don't add the section or follow the convention (ie all existing skins), and nothing changes. The new stuff on the right side of the UI in the helper app would just be empty.

stangowner wrote:Actually, compatibility is not an issue for this change at all. The only change here is the "helper" app (shared memory viewer) that users currently use to update their skin variables manually (a requirement for the plugin). There is no change to HWiNFO, the plugin, or the behavior of the plugin & skin.

So basically, new skins moving forward could create this new [HWiNFO-Config] section, follow the variable naming convention, and therefore give the users of the skin a "friendlier & easier" way to update their variables. Don't add the section or follow the convention (ie all existing skins), and nothing changes. The new stuff on the right side of the UI in the helper app would just be empty.

I think your solution is plenty good enough for my needs, thank you so much. I can deal without the collapsible sections.

A minor question: Am I correct in that it will act like !WriteKeyValue, where it will only change the values of the variables, and leave everything else intact? I would like to be able to combine each gadget's HWiNFO variables with that gadget's existing settings file which already has several dozen variables in it in some cases.

Another thing: When you specify multiple files to be tabs, will the tabs simply take on the filename for the tab label, or will that be changeable (e.g. instead of "GpuSettings.inc" I could make it say "GPU Meter")?

raiguard wrote:Another thing: When you specify multiple files to be tabs, will the tabs simply take on the filename for the tab label, or will that be changeable (e.g. instead of "GpuSettings.inc" I could make it say "GPU Meter")?

raiguard wrote:A minor question: Am I correct in that it will act like !WriteKeyValue, where it will only change the values of the variables, and leave everything else intact? I would like to be able to combine each gadget's HWiNFO variables with that gadget's existing settings file which already has several dozen variables in it in some cases.

Yes, so in the example in the picture.....when you click the "Update" button, it would update (or create if missing):
HWiNFO-CPU0-Temp-SensorId from 0x00000000 to 0xf0000400
HWiNFO-CPU0-Temp-SensorInstance from 0x0 to 0x0
HWiNFO-CPU0-Temp-EntryId from 0x00000000 to 0x100007f
Nothing else would change - only these 3 lines of the file. What you mention is another major reason I don't want to write a full file parser/writer. There could be any amounts of other stuff not relating to me that I need to ignore.

raiguard wrote:Another thing: When you specify multiple files to be tabs, will the tabs simply take on the filename for the tab label, or will that be changeable (e.g. instead of "GpuSettings.inc" I could make it say "GPU Meter")?

Was planning the filename, but I see this would be useful. I''m creating the tab at runtime, so should be easy to do. I'll see about adding this like SilverAzide mentions or a similar means. If provided, use that name. If missing, use the filename.

So the idea is that the basic instructions for using the plugin to create a skin remains the same.

What we would do is add a new section to my "Using HWiNFO" tips & tricks that would describe how a skin "author" can use this new capability to create a skin with a "setup" feature. It would be populated via a .inc file with the sensors, in a general sense, that the author wants to support in the skin. Things like CPU temperature, Fan speed, GPU temperature, whatever. When the "user" activates this setup code, it opens this new tabbed variant of the Shared Memory Viewer, that allows them to just select from a corresponding list of the actual sensor identifiers for their particular system, which they would select and save to change that .inc and refresh the skin.

So the goal here is not to really add anything that makes it simpler to create a skin from scratch, or that is targeted at new or less sophisticated users, but a way to help skin authors, who will need to be reasonably good at Rainmeter, create skins that they can distribute that are easier for the average user to "use".

I don't disagree with it, as I see no logical way to make it easier to understand or use at its core, but I can't say I'm in love with it. I'm generally against trying to isolate users from the underlying code in order to make Rainmeter paint-by-numbers. That's not how we grow new users into authors that fall in love with Rainmeter and get addicted to using it to be creative.

Right now the end user needs to open the inc file and manually copy/paste values from the helper to the inc file. This just gets automated in a friendly way for the user.

I'll have you guys test this and provide feedback before I officially post it.

Update: I see you edited your post.....
Understood, but some users struggle with this plugin because it's one of the hardest to configure. Skin authors get a lot of negative feedback and provide a lot of support. We're just trying to streamline that.
For skin authors, not much is changing. The skin will be the same, just following a standard variable naming convention. But they can also just populate the [HWiNFO-Config] section manually, and use the new helper to automate creating the default variables too.

Last edited by stangowner on March 24th, 2018, 1:22 pm, edited 1 time in total.