fix DpiAwareFont default size calculation #48

Open
momo wants to merge 9 commits from dpi-font-auto-calc into how_to_show_ur_pp
Collaborator
  • Previously, configure_to_dpi() used logical DPI or _font_sizes presets, which produced fonts (~8px) on high-DPI displays.
  • Changed font size calculation to use physicalDotsPerInch() of the screen: font_size = round(inches * pdpi)
  • Ensures consistent, readable default font size based on actual screen DPI
- Previously, configure_to_dpi() used logical DPI or _font_sizes presets, which produced fonts (~8px) on high-DPI displays. - Changed font size calculation to use physicalDotsPerInch() of the screen: font_size = round(inches * pdpi) - Ensures consistent, readable default font size based on actual screen DPI
momo added 1 commit 2025-12-03 21:56:57 +00:00
momo requested review from goodboy 2025-12-03 21:57:08 +00:00
goodboy reviewed 2025-12-03 22:10:29 +00:00
pyproject.toml Outdated
@ -77,6 +77,9 @@ dependencies = [
"trio-typing>=0.10.0",
"numba>=0.61.0",
"pyvnc",
"pyqt6>=6.8.0",

@momo let’s not add these deps to the core set and instead add them to the dev set since we only need them for running this new test suite 🙏

i also wonder if we might want to even consider making a new testing = [] dependency group eventually?

I think for now tossing it into dev is sufficient. Also not sure if uv has a way for deps-groups to depend on others?

Maybe do a quick check for that in their docs too?

@momo let's not add these deps to the core set and instead add them to the `dev` set since we only need them for running this new test suite 🙏 i also wonder if we might want to even consider making a new `testing = []` dependency group eventually? I think for now tossing it into `dev` is sufficient. Also not sure if `uv` has a way for deps-groups to depend on others? Maybe do a quick check for that in their docs too?

Also not sure if uv has a way for deps-groups to depend on others?

looks like nope says gemini Xp

uv does not currently support nesting dependency groups directly within the pyproject.toml file in a way that one group explicitly “includes” another in the same manner as, for example, extras can be defined to include other extras. However, you can achieve a similar effect by managing your uv commands to include multiple groups when performing operations like sync or pip install.

> Also not sure if uv has a way for deps-groups to depend on others? looks like nope says gemini Xp > uv does not currently support nesting dependency groups directly within the pyproject.toml file in a way that one group explicitly "includes" another in the same manner as, for example, extras can be defined to include other extras. However, you can achieve a similar effect by managing your uv commands to include multiple groups when performing operations like sync or pip install.
goodboy reviewed 2025-12-03 22:14:29 +00:00
@ -0,0 +15,4 @@
# pass the mock screen to configure_to_dpi
font.configure_to_dpi(screen=MockScreen())
print("Computed pixel size:", font.px_size)

woo nice!

this is a good start but we should wrap this in a pytest test-fn (function) so that it will report like the rest of the test suites ;)

https://docs.pytest.org/en/stable/getting-started.html#create-your-first-test

woo nice! this is a good start but we should wrap this in a `pytest` test-fn (function) so that it will report like the rest of the test suites ;) https://docs.pytest.org/en/stable/getting-started.html#create-your-first-test
goodboy reviewed 2025-12-03 22:19:22 +00:00
@ -183,3 +183,3 @@
# float to px size: int.
self._font_inches = inches
font_size = math.floor(inches * dpi)
font_size = math.floor(inches * pdpi)

Yeah, it’s funny that this worked for you since the non-physical DPI is supposed to be the one that “you perceive on screen given DE scaling compensation” ..

so it does indeed look like we might always want/need to do from-scratch analysis of every display’s reported DPI and totally ignore OS-dependent metrix/reports including those with supposed auto-scaling.

Yeah, it's funny that this worked for you since the non-physical DPI is supposed to be the one that "you perceive on screen given DE scaling compensation" .. so it does indeed look like we might **always** want/need to do from-scratch analysis of every display's reported DPI and totally ignore OS-dependent metrix/reports including those with supposed auto-scaling.
momo added 1 commit 2025-12-08 20:30:01 +00:00
momo added 1 commit 2025-12-09 03:17:05 +00:00
momo added 1 commit 2025-12-09 03:22:37 +00:00
momo added 5 commits 2025-12-22 21:47:59 +00:00
35744f666f Add some Qt DPI extras to `qt_screen_info.py`
- set `QT_USE_PHYSICAL_DPI='1'` env var for Qt6 high-DPI
  * we likely want to do this in `piker.ui` as well!
- move `pxr` calc from widget to per-screen in loop.
- add `unscaled_size` calc using `pxr * size`.
- switch from `.availableGeometry()` to `.geometry()` for full
  bounds.
- shorten output labels, add `!r` repr formatting
- add Qt6 DPI rounding policy TODO with doc links

(this patch was generated in some part by [`claude-code`][claude-code-gh])
[claude-code-gh]: https://github.com/anthropics/claude-code
49bedb4912 Reorder imports in `qt_screen_info.py` ??
For wtv reason on nixos importing `pyqtgraph` first is causing `numpy`
to fail import?? No idea, but likely something to do with recent
`flake.nix`'s ld-lib-linking with `<nixpkgs>` marlarky?
e63cffaf53 Add `.xsh` script mentioned in gitea #50
Note since it's actually `xonsh` code run with either,
- most pedantically: `xonsh ./snippets/calc_ppi.xsh`
- or relying on how shebang: `./snippets/calc_ppi.xsh`
  * an sheboom.

Hey @momo sorry about the delay getting you a rebase cmd!

Looking at the old history the rebase cmd you need should be something like,

git rebase 3751140f dpi-font-auto-calc --onto=main

where commit 3751140f should have a message like,

ib: bump docker/ib/README.rst

i believe, and it should still be the first commit from before you created your new dev branch dpi-font-auto-calc.

During this rebase you will hit some conflicts on pyproject.toml and uv.lock because it looks like you changed those but they’ve already been better re-orged and set upstream on main now (also i know about the conflicts bc i already tested the git rebase cmd i provide above ;).

The commits that touch these i think are,

so when you hit conflicts what i’d recommend is doing,

git status/diff  # just if you want to see the conflicted files
git reset uv.lock pyproject.toml
git checkout --ours uv.lock pyproject.toml
git add uv.lock pyproject.toml
git rebase --continue

i believe the 2nd commit actually changes uv.lock without conflict, but i’d still like to have the main version of it be what you base your work on before changing it; pretty sure you won’t need to change it either bc now we use [dependency-groups] more correctly and with the --dev group actually nesting them nicely.

if you run into any issues you can always do,

git rebase --abort

to start over from the beginning.


once you’ve successfully rebased the way i would want it the history should look like the image i’ve uploaded,

Hint you can see something similar on console by using the cmd,

git log --graph --oneline --decorate --all ( i alias this in my global .gitconfig as logtree)


as always if you have an questions or what to go into more detail about all this just hit me up on chat ;)

Hey @momo sorry about the delay getting you a rebase cmd! Looking at the old history the rebase cmd you need should be something like, `git rebase 3751140f dpi-font-auto-calc --onto=main` where commit 3751140f should have a message like, > ib: bump `docker/ib/README.rst` i believe, and it should still be the first commit from *before* you created your new dev branch `dpi-font-auto-calc`. During this rebase you will hit some conflicts on `pyproject.toml` and `uv.lock` because it looks like you changed those but they've already been better re-orged and set upstream on `main` now (also i know about the conflicts bc i already tested the `git rebase` cmd i provide above ;). The commits that touch these i think are, - c6c768e - 7ff4f5d so when you hit conflicts what i'd recommend is doing, ```sh git status/diff # just if you want to see the conflicted files git reset uv.lock pyproject.toml git checkout --ours uv.lock pyproject.toml git add uv.lock pyproject.toml git rebase --continue ``` i believe the 2nd commit actually changes `uv.lock` *without* conflict, but i'd still like to have the `main` version of it be what you base your work on before changing it; pretty sure you won't need to change it either bc now we use `[dependency-groups]` more correctly and with the `--dev` group actually nesting them nicely. if you run into any issues you can always do, `git rebase --abort` to start over from the beginning. --- once you've successfully rebased the way i would want it the history should look like the image i've uploaded, Hint you can see something similar on console by using the cmd, `git log --graph --oneline --decorate --all` ( i alias this in my global `.gitconfig` as `logtree`) --- as always if you have an questions or what to go into more detail about all this just hit me up on chat ;)
momo force-pushed dpi-font-auto-calc from 6ee0d86548 to e1a81fa433 2026-01-13 03:58:42 +00:00 Compare
Poster
Collaborator

@goodboy how it looks? there is no conflicts now

@goodboy how it looks? there is no conflicts now
This pull request can be merged automatically.
You are not authorized to merge this pull request.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b dpi-font-auto-calc how_to_show_ur_pp
git pull origin dpi-font-auto-calc

Step 2:

Merge the changes and update on Gitea.
git checkout how_to_show_ur_pp
git merge --no-ff dpi-font-auto-calc
git push origin how_to_show_ur_pp
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: pikers/piker#48
There is no content yet.