Added new "Allow themes to change module icons" to the Theme Options dialog in the General tab of Preferences. Enabled by default, themes are not allowed to change the current settings of the iconic modules when disabled (so module icon colorization settings are not overridden when you switch to a different theme, etc).

Also added right click context menu options to convert sub-docks to Grid Stacks and Grid Stacks of Regular type to sub-docks.

I am going to ask a potentially very silly question (sorry)...
I want to make sure I read this correctly.
"Allow themes to change module icons" to the Theme Options dialog

Does this mean there will also be a default initial theme choice added into the configuration file for a skinner? I have zero issues with any user overriding it but it is handy if someone downloads a theme that it displays as intended initially.
If not - It does not bother me to write something like:
"Disk looks most appropriate in this theme with the Torus" or something like that in the download notes, but hopefully that question was not too silly, because it would be convenient though not important.

Second part of dumb question time:

does this mean that when a user does a Save desktop module.... that it saves H/V and icon?
Just asking. Again, does not matter if the Global preference does not include that, I just wanted to be sure I completely understand the depth of your addition and how far it carrys over

That setting does what it says and has nothing to do with skinners. You do not need to write "this theme looks more appropriate with the themes icons/colors", the user already knows that. Anyone unchecking that setting will do that deliberately, knowing full well what it does.

What "Save desktop module" option are you referring to?! It has nothing to do with the disk meter or with saving, or with changing existing themes.

When you clear that setting all that happens is:

1. This does not affect desktop modules AT ALL except if they display an image of the iconic version of the module, and then it only affects the icons they display.

2. Any icons that belong to the current theme are no longer applied. The modules will use the default icons or any user specified icons set via the module's "Change Icon" button.

3. Colors (e.g. color of the ICONIC clock face, clock hands, etc) and color schemes (e.g. color customizations you make for the disk meter icons via the Icon Factory) will remain even when you switch to a different theme, instead of being overwritten by it.

All I wished to know was how deep it went or if it was to be taken at face value. It is the latter that is all I wanted to know.
Thank you.

I also got gauges working - worked out how to do the configuration by myself. . They are useful for spikes. The horizontal blank bar at the base of the gauge is where the multi is. The C drive is active in the image.
Thanks for your assistance though as I said, I ended up working a lot out for myself, it did help point me in the right direction though

Here it can be seen more clearly that the histo's "zero" activity level indication is in a different position for read and write. I've never ever seen that in any other meter app with multiple measurements, they always start from the same position in the graphic, e.g. CPUs, regardless how many cores there are, they are always starting at the same level and overlap according to activity. Thus, there is always a reasonably accurate indication of the % load on a given core at any point in the time covered (usually 60s).

The histo as is with the different levels and no indication of time is hardly useful in my considered opinion, sorry Jorge.

Here I agree with Nexter, BassDudeNZ. The y position for the Write graph should be the same as the y pos for the Read graph.



Beg to disagree. Despite being a dynamic graphic (which it has to be because we are not measuring fixed scales like 0 to 100%, but through output, the maximum of which depends on the actual hardware*) the read and write scale values (i.e. what is currently the maximum value for that graph) are synced using the new SyncMeters setting.

What this means is that the graph will use the SAME max scale for BOTH values, so read and write peaks are always on the same scale. This max scale value will remain stable for 60 seconds unless a new burst of activity forces the scale to change to accommodate a new max.

If the read graph is two times higher than the write graph, then you know that read through output is EXACTLY twice write through output.

The instant read and write text values also give you a pretty good idea of what the current scale might be (and for other themes than the default with perhaps more space, one of the options you can display is current scale value).

As for time, it is ALWAYS last 60 seconds.

The idea is not to know EXACTLY what data through output was in the last minute by the second, but to have a pretty good idea of what is going on with that drive in terms of data transfer.

* Dynamic like the Bytes Sent and Read graphs in the DarkTech desktop net meter, for instance, although in that case it uses a bar rather than a histogram.

This is where I wanted to inaccurately say it is your fault for saying in another post you could not differentiate between which graph was which because they were the same colour
However - it is TRULY no big deal, because the only difference is the positioning orientation. The vertical pixel start point on R & W is simply separated for clarity of vision. - it is a piece of cake to put them in the identical Y position. While you are 100% correct that in real terms they should not be separated, I did notice when I purposely made the drives go crazy by doing an intensive defragmentation, if they were on the same line, occasionally, the only separation was the colour difference because each would occasionally fill from the peak points. By separating, you can clearly see the differences. As mentioned no big deal Yes I can turn the fill off too I think? - and only have lines, there is a setting in the config file. I just haven't tried it.

Also with the gauge - after Jorge saying it would be radical which is also 100% correct, it definitely shows fast spikes which is why I did it in this specific theme because that theme is decked out. I won't be doing it often and that's the truth, but I know how it functions and I can say I tried it without a complete fail so I am content

Ok set fill to false and both on identical Y coordinate. I can lower them but I chose not to for visibility only. theoretically, while on a graph, 0 is generally bottom left corner, the zero is actually the starting reference point which makes everything below the line negative.
Easy peezy.

Oops, sorry Jorge, I laboured under the false impression that the Y positions were fixed.

Yes, I get all that Jorge. However, Personally, I don't really want to have to look at a load of separate written data but rather, just a simple informative graphic by preference. Thus, in the case of a histo for drives, I'd want to see a scale indication on the Y axis to one side of the histo, which would adjust its values as and when needed, and a fixed time scale indication on the x axis under the histo. We've had exactly that for ages in *nix-like OSs like Linux, and even in earlier OSs. My personal preference anyway. Although, for slightly more static displays especially my preference goes to bar graphs.

Mine too, which is why I added the option to display current scale level(s) to the desktop meter for skinners to take advantage of if they so wish (and the time span of information displayed is fixed at 60 seconds, so...) but to keep the default desktop meter compact and make everything fit in the small space of each drive section, choices had to be made.

Personally I think it's good enough as is... as I said, even if the current scale is not displayed anywhere, the real time read/write values give you a pretty good idea.

It does matter a great deal to have both graphs start from the same Y base line - otherwise, you couldn't judge the relative ratio of read to write when both are active.

That's a lot better. Fill is never a good idea, AFAIC, so good that it's gone. The problem is still that the histo graphic doesn't have any indication of scale on the vertical axis nor an indication of time scale on the horizontal. However, with such a small graphic that's not even really feasible anyway, alas. Hence, bar graphics would be more useful in this situation. Just my personal opinion and preference.

Although I think we're otherwise pretty much agreed here Jorge, as I said before, I would not want to have to look at a separate text read/write value. But of course, with the small space for the graphic, I accept scale indications aren't really feasible at all. Hence it's obvious that bar graphs would far better utilise the space available.

@Jorge

- Bug or by design?

Ticker does not seem to be working?

I can name two for a start, particularly 03H/V and 04H/V where it would be very useful because for information, putting in a prefix will not show the information properly in the module... what would need to scroll..
e.g 03H... Drive Model = and 10H Model Number =
File system and others where information will be more useful to the average user with a prefix.

Perhaps I entered the wrong line manually (which isn't there)?
DiskTicker03H=True (does not work). I got around it by making the font smaller and M#=
The other thing I thought of was the text width. Does it need to be a specific size to force the ticker to work and require another line? Like DiskMaxWidth03H=? That does not seem to make any difference either.

If it is different to the other modules and by design, please let me know the correct line to put in
Thank you

By design. The ticker mechanism was never designed to work with multiple drives, so rather than re-invent the wheel I simply decided to disable it for the disk meter.

Might give it another try in a future version.

Hmm, having that on with multiple drives could have quite a performance hit for users with older/less beefy hardware I'd think?

Not necessarily, although anything that uses resources adds up to the burden, of course.

That is also why "Enable smooth text scrolling" is one of the settings in the very much never remembered Advanced Performance Settings dialog (Preferences -> Advanced tab -> Performance Settings -> Advanced). Clear that setting and ticker text scrolls character by character instead of pixel by pixel, which greatly reduces CPU usage of the feature.

The actual problem is that I would have to re-do the whole ticker system from scratch to make it work with the multiple sections/drives of the disk meter module and I really don't feel like doing that at this point.