Improvement to ManageRainmeter window...

[sl23]

After a short discussion with Yincognito, I decided to make a request, which hopefully isn't too hard to implement.

Basically, the Manage window is awkward to use when needing to constantly refresh skins due to the fact that it closes all the open folders in the tree list. But also, having this tree list is also confusing at times.

A much simpler to use solution would be to implement a different structure. At first I thought, keep the folders open on app refresh, but this can be messy, especially when you have many. So then I thought about having the Skin INI files listed with their ConfigName as a prefix. But this also gets messy.

So perhaps a better solution is to have a similar layout to the About/Skins window. Not the left pane, but the right pane.
Where you have:
Measures--------------- in blue,
and a list of them underneath, then:
Variables------------ in blue
and a list under that.

Thus having:
ConfigName1----------- in blue,
Skin1.ini
Skin2.ini
Skin3.ini
ConfigName2----------- in blue,
Skin1.ini
ConfigName3------------ in blue,
Skin1.ini
Skin2.ini
etc...

This would reduce the clutter of folders and make things easier to see at a glance. I guess it's not likely to happen this way, if at all, but can't hurt to ask!
Also, the code is there to be used and transferred as necessary, so win win!

[Cariboudjan]

Having variables flash a colour briefly when they change would also be nice.

And possibly the option to pin a variable/measure to the top.

Better window handling when Rainmeter is HighDPIAware.

Ability to open the specific config's about pane from the right-click menu or from the system tray without having to about System tray >> About >> Skins tab >> Select config

Have the Rainmeter about pane stop updating when it isnt in focus, so it doesnt lag the PC when opened with many measures/variables.

Have expandable trees in the config selection pane so all configs belonging to the same root config are grouped.

Ability to sort measures by Calc, String, Plugin, etc.

A search box for finding the measure/variable.

[sl23]

Some really good ideas there!

One thing I've really found annoying, is the lack of ability to set the About window to stay on top when working on a full screen skin, minus taskbar.

[Yincognito]

Have the Rainmeter about pane stop updating when it isnt in focus, so it doesnt lag the PC when opened with many measures/variables.

I'm all for eliminating that lag if possible, but I'd rather not have to constantly click the About pane window after clicking in the skin, in order to see the values of measures and variables updated, not to mention that this could potentially confuse users who forget to focus it into thinking that those values don't change. Unless you meant that it shouldn't update the tabs that aren't currently selected / in view, which won't have any obvious downside.

[jsmorley]

The About/Skins panel simply must be updated in real time to be of any real diagnostic value - in my view. As I recall, only the skin that is currently being displayed updates in real time. This is all as it should be.

[Yincognito]

The About/Skins panel simply must be updated in real time to be of any real diagnostic value - in my view. As I recall, only the skin that is currently being displayed updates in real time. This is all as it should be.

An idea: instead of an entire skyscraper sized tableview control that actually scrolls for skins with many values, how about a tableview control strictly the size of the viewport, that just changes the values displayed in its cells to simulate scrolling? Obviously then, the "scrolling" would have to be row based.

I mean, if the lag is related to the "redrawing" (in memory or visually) aspect of a very "tall" tableview "page" like in a browser, approaching this the other way would almost certainly improve performance. Just saying, whether it's worth the time to change the current system and implement it, that's up to you guys.

[Yincognito]

Quick update - just noticed that the About > Skins data is collapsible. I wonder if collapsing the variables and measures sections would also improve performance (if the cause is redrawing the contents of the tableview, that is). I just don't have a proper (huge and frequently updated) skin to test this with...

[jsmorley]

Quick update - just noticed that the About > Skins data is collapsible. I wonder if collapsing the variables and measures sections would also improve performance (if the cause is redrawing, that is). I just don't have a proper (huge and frequently updated) skin to test this with...

I imagine it would. Not 100% sure on that, but in any case, that is a list "control", and there is no practical way to update only "part" of a control.

[Yincognito]

I imagine it would. Not 100% sure on that, but in any case, that is a list "control", and there is no practical way to update only "part" of a control.

Yep, you're right, I tested it in the meantime. For a 6.5% overall CPU usage when one of my skins is displayed with that tab opened, collapsing both the variables and measures sections gets the CPU to 4.5% usage. For another where my overall CPU goes to 10.5% usage, complete collapsing gets it to 8.5%. All are approximate values, of course. So, unfortunately, the visual side of the redrawing isn't the whole (or even the main) issue, like you mentioned.

I know you can't update only a part of a listview control, that's why I thought about making it a table just the size of the viewport and changing what's displayed in its cells instead. Too bad that the visual side isn't the main cause of this lag, because if it were, the solution was simple IMHO.