[Bug]: conky pixel unit isn't scaled by screen DPI about conky HOT 25 OPEN

Closing this as wontfix because I don't see it as a bug and the introduced changes make conky behave correctly (more in line how other software (e.g. browsers) works).

I was under the impression browsers changed the size of the logical pixel, just like conky used to do.

from conky.

Ah: the problem seems to be as follows. Between this build and the last (or perhaps the one before last) the handling of maximum_width has changed. Seemingly, now, that variable should be set to the actual, full resolution (if one wants to use the full screen), rather than - as it was before - to the resolution as understood after DPI scaling. I presume that the same holds for minimum_height.

(The config I posted lacks those variables: I have them in a separate lua file - or a file that differs across the two PCs at issue.)

It seems to me that either the behaviour should be reverted or else users should be made aware of the change.

from conky.

@zygfryd You're right. The exact name for the scaling factor used is Device Pixel Ratio (dPR). Though it's almost a standard practice for websites to set <meta name="viewport" content="width=device-width, initial-scale=1.0"> which sets dPR to 1.0 and makes px respect actual pixel size.

That actually just scales your app 1:1 to the viewport in logical pixels. On a phone it'll mean you'll be working with widths in the 300-400px range, not the physical 1000px+ range. Otherwise the usual method of width breakpoints for responsive design wouldn't work.

Anywho, I was planning on adding a way of handling different units which would default to something like "logical pixels" if no unit was specified. I see how current behavior could be confusing. While I do believe px unit should really be pixels and not adjusted because it's misleading otherwise (e.g. scaled/blurry images even though exact px size is used), I explored what other UI is doing a bit more and it seems most of UI toolkits do scale the px value so I decided to reopen this issue.

Glad to see that.

From a user's perspective, it'd be ideal for a conky config to work like it used to in 1.19, that is regardless of monitor density the conky window takes the same, scaled, amount of logical space. Desktop scaling is a decision the user makes and shouldn't be worked around, but respected. If the user wants to work around it, then conky might give the option of overriding the scaling factor it obtains from X11 or Wayland.
It'd be tedious to have to rewrite all the sizes in your config when moving between monitors with different densities and scaling factors.

from conky.

It seems to me that either the behaviour should be reverted or else users should be made aware of the change.

It's impossible to make a consistent looking configs if maximum_width depends on DPI. This was cause of #1528. Given that conky uses pixel size for most things (e.g. image size), automatic scaling of only certain properties is (I believe) wrong. It would maybe make sense to add a separate global scaling factor.

#1877 and #1862 fixed this partially.

I just created #1926 as I found another place where maximum_width was scaled. I also removed scaling of minimum_width.

It's a bit confusing because we're not using units like rem/em/ch, and pixel dimensions should be affected by DPI. But if we scale px, the unit should really be considered pt at that point (hah, punny). Likely the next step would be adding a unit resolver that allows configs to specify different unit values like CSS does and make the number without any units default to pt which would revert the old behavior - this would provide means to fix most inconsistencies when it comes to content sizing.

from conky.

I made the name of the PR clear (which is referenced in release notes), besides that I'm not sure how we can make it clearer that the behavior changed.

Closing this as wontfix because I don't see it as a bug and the introduced changes make conky behave correctly (more in line how other software (e.g. browsers) works).

from conky.

@Caellian

Thank you for the responses.

So, now and henceforth DPI scaling will not affect minimum_width and maximum_width? That is what your last post says, I take it. Still: your first post (here) seemed to suggest that, no, things would be put back to how they were before; but I understood that first post only poorly. (For, that post is technical.)

I'll go with the 'wontfix' interpretation (as we might call it). Given that situation, I proceed to the following.

I'm not sure how we can make it clearer that the behavior changed.

You could add a conspicuous comment to the release that made the change. That way, users like me how installed that release (which was either the most recent one or the one before that) will not get a nasty surprise.

from conky.

Release notes are generated from PRs. The bug fix PR that changed behavior did say that max width no longer uses DPI in the title, so it was in the release notes.

from conky.

My mistake. Apologies.

from conky.

I'm using Wayland with 200% scaling on 4K monitors.

In 1.19 the scaling was consistent:

In 1.20 graphical elements are now at 100% scaling while fonts are at 200%:

I'm skeptical about this being an improvement. I guess I need to stick to 1.19 until the global scaling factor gets implemented?

from conky.

@zygfryd You're right. The exact name for the scaling factor used is Device Pixel Ratio (dPR). Though it's almost a standard practice for websites to set <meta name="viewport" content="width=device-width, initial-scale=1.0"> which sets dPR to 1.0 and makes px respect actual pixel size. dPR is based on DPI, but it's not an exact match (adjusted for expected screen viewing distance).

This was necessary because old phones (iPhone) had to make websites smaller to fit the screen, so they reported incorrect screen dimensions to websites/browsers to achieve this effect. Logical dimensions were introduced in order to make (mostly) images behave correctly on different DPI screens.

Anywho, I was planning on adding a way of handling different units which would default to something like "logical pixels" if no unit was specified. I see how current behavior could be confusing. While I do believe px unit should really be pixels and not adjusted because it's misleading otherwise (e.g. scaled/blurry images even though exact px size is used), I explored what other UI is doing a bit more and it seems most of UI toolkits do scale the px value so I decided to reopen this issue.

from conky.