Yes, it is supposed to be a fixed size image so you can overlap a static bitmap on top of the disk meter module at a fixed position. Stretching it automatically would just distort the image, IMO, unless you start treating the overlay as you do the primary disk meter container, which at this point is beyond the scope of the overlay.



Ok, hold on, why do you claim this has anything to do with the overlay? Aren't you using WsDiskGauge.png bitmaps for the gauge needles?

Notice how drive F is the only drive with the needle all the way to the right? Since the needle bitmap is rotated by the application to point to the proper location, my guess is that this might have something more to do with how the needle is centered in the bitmap - or a coordinates issue - than anything else.

It also may or may not be a bug in the application.

As I told you previously, most of the skinning stuff was implemented a long long time ago, so I don't remember how it works anymore. To refresh my memory I will have to spend some time looking at the code again, but for that I need the needle bitmap and the coordinates you are using as reference.



I VERY MUCH agree with you actually, and this also makes much more sense than stretching the module overlay (you would be able to optionally use both anyway, so any work BassDudeNZ has already done using a disk overlay would not be affected). However, not sure I will be able to implement such a thing in time for the v26.1 release.

Yes, in the previous Disk Office screenshot, I'm using the WsDiskGaugeUsed.png bitmap, the same one I used for CPU and RAM in your Office theme, with the following settings:
DiskShowGauge03V=True
DiskGaugeDraw03V=False
DiskGaugeThickness03V=2
DiskGaugeRadius03V=32
DiskGaugeColor03V=0
DiskGaugeXpos03V=221
DiskGaugeYpos03V=43
DiskGaugeStartAngle03V=270
DiskGaugeSpan03V=180
DiskGaugeInterval03V=0
DiskGaugeClockwise03V=True
You can see that when the needle is on the left, its center is indeed in the center of the graph, and as soon as it moves to the right, its center shifts 2 pixels upwards and 2 pixels to the right.

You can see that when the needle is on the left, its center is indeed in the center of the graph, and as soon as it moves to the right, its center shifts 2 pixels upwards and 2 pixels to the right. I've already encountered this problem on other themes using the gauge.

That's why, in the Office V2 theme I uploaded, I used a simple needle without its central circle for the RAM and CPU modules, and the central circle as an overlay to prevent it from moving.
As a result, only the needle moved upwards and to the right by 2 pixels, not the central circle, making it all visually acceptable.

I don't know if this is a bug or normal behavior; I have no idea.

I noticed that the settings are slightly different in degrees to make sure the needle moves where I want it to. It is not always the same for each module that supports a gauge either. Funnily enough the one that works best for me is the battery.
I made one for my laptop and let the battery run flat then recharged it observing the gauge.

Disk gauge - I found that the disk gauge catches the spikes mainly. It seems to work much like the LED's except not as frequently. You sound like you have spent more time on it. so you have probably got a lot further.
I am not sure if it is a bug or normal behaviour either.


P.S - Thanks for the smart tip with the circle overlay. That was bugging me too that even with a perfect circle it looked wonky every so often.

Yes, after checking the code this is because of two problems:

1. I'm using the integer version of GdipDrawImageRectI to draw the needle. For odd sizes images (e.g. like that 23x59 needle bitmap, center of the needle would be 11.5 and 29.5) the integer draw can bias the center/pivot point by 1 pixel.

2. I am also flipping the bitmap by 180º which can add up to the rounding error introduced above.

I can try not rotating the bitmap and using the floating point versions of that GDI+ call to see if that fixes the issue.

Can you please send me the bitmaps and configuration file for the Office Disk Meter module to the Winstep support address?

Ok, I fixed the gauge rotation code so it is now mathematically correct and using floating point instead of integers.

This said, it still cannot fix a bitmap that is misaligned in its center, such as the gauge needle bitmap in the office theme.

The WsCPUGauge.png is a 23×59 bitmap. The geometric center is:

cx = (23-1)/2 = 11

cy = (59-1)/2 = 29

But the center of the hub/cap in the bitmap is lower (+- y = 33). That means the hub is about 4 px below the bitmap center.

So if we rotate around bitmap center, the hub will orbit with radius +-4 px. Between two angles (0% vs 100%), an orbit of radius 4 px very naturally shows up as +-2 px shift in x/y.

With the new code the "drift" between 0% and 100% is now only 1 pixel instead of the previous 2 pixels up and to the right. Better but not perfect, and the only way to fix this is by using a new gauge bitmap where the pivot point of the needle is perfectly centered.

Thanks my understanding is more general. what I grasped was that if I wanted the gauge to treat '0' as the lowest point in a gauge map that went from 9 o'clock to 3 o'clock, it was 270 degrees and Radius was 180 degrees. If 7 o'clock to 5 o'clock it was 240...so on and so forth.
I do know that I will have to redo some of my gauges because I know of at least two that are misaligned to accommodate incorrectly (by me) and that is fine because all my images are layered. Yes I do understand floating points and the thanks was sincere.

I can add these per-section overlays, but to make things simpler so I don't have to add more settings, any objection that the section overlays always start at 0,0 (in relation to the section) ?

Or would you need at least x,y coordinates (relative to the start of each section, i.e. WsDiskSectionOverlayX=x and WsDiskSectionOverlayY=y ) ?

For an overlay, I always start from point 0. Then it's up to each user to build their overlay and set the values ​​they want.

Yes, I think all the parameters would be necessary if possible, without wanting to cause you any trouble or extra work.

WsDiskSectionShowOverlayH=True
WsDiskSectionOverlayXposH=0
WsDiskSectionOverlayYposH=0
And
WsDiskSectionShowOverlayV=True
WsDiskSectionOverlayXposV=0
WsDiskSectionOverlayYposV=0

Thank you for everything...
PS: I'm sending you the vertical section of WsDisk Office.

My two cents worth - everything in every module's configuration already has X and Y coordinates and having everything default at 0 is how I personally do it if I want to do something different, because what exists won't work anyway if the creative idea is very radical anyway. So I end up putting all overlays at zero so I have a reference point for the X and Y coordinates as to whether I need to move something in a negative direction, or if I have to redo the orientation of backdrop. That also works for objects in 2D graphs or in the circumference of a 2D circle/gauge for me.

I just saw Picco's post - yup - same but different.

Which will be causing me extra work anyway lol

No problem, let's see how quickly I can implement and test this (I had already started after my last post anyway lol). Once it's done I'll issue a last *very quick* beta. This means you will only have a couple of days or so to test the per-section overlays before the official release - sorry about that but being this close to the end of January there is no way around it.



Got it, thanks! I'll test it and then reply by email.

The 1 pixel drift you are still experiencing there after fixing the gauge bitmap should be gone with the new code, but at the time I am writing this I still haven't tested it.

And there you go, a vertical iStat Disk Meter desktop module with a nice per-section glass reflection overlay:

And one with a glassy histogram section:

So, the brand new section overlays seem to be working fine.

New betas of v26.1 are out:

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

Nexus Ultimate beta:
https://www.winstep.net/ultimate-beta.zip


This is a beta and MUST be installed ON TOP of a full v25.9 OR LATER installation. Do NOT uninstall anything first, just exit all running Winstep applications and run the beta setup file.

There is no need to backup your settings first, but it does not hurt if you do either.

####

This should be the last beta before the official release (where have I read this before? - now seriously, we only have a couple of days before I have to officially release this thing)...

This version should have fixed the "drift" in gauge needles, adds support for per-section disk meter overlays (WsDiskSectionOverlay.png, WsDiskSectionOverlayV.png) with

WsDiskShowSectionOverlayH=True <---- NOTICE THE NAME
WsDiskSectionOverlayXposH=0
WsDiskSectionOverlayYposH=0
And
WsDiskShowSectionOverlayV=True <---- NOTICE THE NAME
WsDiskSectionOverlayXposV=0
WsDiskSectionOverlayYposV=0

settings.

Added ability to convert sub-docks to grid stacks and vice-versa, and there have also been A METRIC TON of enhancements and a huge increase in the robustness of drag & drop operations and management of docks, sub-docks, grid stacks, launch pads, etc...

To see a complete list of changes, fixes and additions, right click the version number on the top right corner of the About tab of Preferences and click the "View Change Log" button.

After installing the latest beta, when I run the launcher for Command & Conquer The First Decade, the launcher window does not show on the screen and it doesn't show that it is running on the tasklist . The Task Manager and Foretester both show that it is running though.

This happened on Windows 10 and Windows 11. Both are the latest versions.

I was also running Start11, Windowblinds 11, and ExplorerPatcher. I uninstalled ExplorerPatcher, Start11, and Windowblinds 11 and the problem still occured.

If I run the laucher from a desktop shortcut it works just fine.

I could not add a screenshot showing the launcher working on the previous beta on my last post. Here it is.

I also forgot to add that I tried starting the laucher from a Grid Stack and from a Shelf. It did not work from either one.

After further testing I found that if I add the desktop shortcut that I created for the TFD Launcher to a Grid Stack it works ok.

If I try to start the launcher from the original Grid Stack entry, the launcher window does not show on the screen, but when I move the mouse over the area where the launcher window should be, the mouse pointer flickers when I move it.

Can you please post a screenshot of the ***Winstep**** Item Properties dialog for the item that does not work and for the item that does work? Would like to see the difference.