Width of fixed-width fields in `wxStatusBar` is not scaled on DPI change (Issue #27182)
taler21
taler21 created an issue (wxWidgets/wxWidgets#27182)This issue can also be seen in the statbar sample.
To Reproduce:
- Start the statbar sample at a DPI scaling of 100%.
- Set the field count to 2 by clicking on 'Status bar' and 'Set field count' or by pressing
Ctrl+C.
Image: Image (view on web) - Change the DPI scaling to 200% or move the window to a monitor with such DPI scaling.
The width of the fixed-width field is not adjusted to the new DPI.
Image: Image (view on web)
Platform and version information
- wxWidgets version you use: master (08416d3)
- wxWidgets port you use: wxMSW
- OS and its version: Windows 10 and 11
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Steve Cornett
stevecor left a comment (wxWidgets/wxWidgets#27182)The wxStatusBar behavior is correct. The documentation for wxStatusBar::SetStatusWidths() says fixed field widths are in pixels, which means physical pixels. It's up to the application to adjust for high DPI, if needed. This is covered in the documentation topic "High DPI Support in wxWidgets".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#27182)Sorry, I don't think "pixels" means "physical pixels", it's stated, in the same overview, that all coordinates/dimensions/sizes are in logical pixels by default except when explicitly stated otherwise and I don't see why should status bar field widths be an exception. IMO it's a bug, just one I have no time/energy to fix right now...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Steve Cornett
stevecor left a comment (wxWidgets/wxWidgets#27182)I'm confused. I see documentation and behavior that also indicates pixels are physical pixels. For example:
Generally speaking, adding support for high DPI to the existing wxWidgets programs involves doing at least the following:
- Not using any hard-coded pixel values outside of FromDIP() (note that this does not apply to XRC).
and:
Thus, the first thing do when preparing your application for high DPI support is to stop using raw pixel values, ...
For example, if you have the existing code:
myFrame->SetClientSize(wxSize(400, 300));
you can just replace it with
myFrame->SetClientSize(myFrame->FromDIP(wxSize(400, 300)));
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#27182)Sorry, I reacted just to the "pixels == physical pixels" comment, but you're right that the status bar widths should be expressed in logical pixels, i.e. use FromDIP() in the sample.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.