Page MenuHomePhabricator

Closed, ResolvedPublic


|interface Efl.Screen
|├ (P) screen_size
|├ (P) screen_rotation
|├ (P) screen_dpi

Related Objects

zmike created this task.Jan 8 2019, 11:54 AM
zmike triaged this task as TODO priority.
segfaultxavi moved this task from Backlog to Evaluating on the efl: api board.Feb 5 2019, 4:01 AM

What is "size"? is that the physical size of the screen or the resolution of it?

Assuming it's physical size, should resolutions be exposed as well?

Technically, (current) dpi is derived from physical size and (current) resolution.

Wayland has a per screen scale factor as well, which is what oldschool X people should actually be fiddling with when they try to mess with server dpi - should this factor be exposed as well?

I agree size does not say whether it's in pixels or inches.
Even if it's redundant, I would expose size in pixels, size in inches and DPI, so it's easier for the user.
With the same spirit, if there's a scale factor laying around, I would also expose it, and all the measures again with and without it (as in size_in_pixels and scaled_size_in_pixels).
These things tend to be very confusing, so it doesn't hurt to be verbose.

As I checked ecore_wl2_display_screen_size_get and ecore_wl2_output_dpi_get, currently the property "screen_size" is used as a resolution. (not physical millimeters or inches).
"screen_size" is received from width(width of the mode in hardware units) and height(height of the mode in hardware units) of mode in

So as you said, we can find out which is the more accurate property name for this case instead of "screen_size".
Only one thing I am concerning is that it describes "hardware units". I am not sure if we can always say that the "hardware units" is "pixels" or "resolutions".

So maybe something like:

  • screen_size -> screen_size_in_pixels
  • add screen_scale_factor
  • add screen_size_in_mm

I don't think it's great to have more properties for scaled sizes?

I've created patches for the above, though the new properties lack implementations. This can be solved at a later point.

zmike moved this task from Evaluating to Stabilized on the efl: api board.Feb 21 2019, 11:08 AM
bu5hm4n raised the priority of this task from TODO to Normal.Feb 22 2019, 1:19 AM
zmike closed this task as Resolved.Mar 11 2019, 10:47 AM
zmike claimed this task.