P: SDK: LrSystemInfo.displayInfo() and .appWindowSize() return wrong units of pixels on Windows

[johnrellis]

On Windows, when the user has set Preferences > Interface > Font Size to Large, Larger, or Largest, it's impossible for plugins to properly size large controls and dialogs.  This is because LrSystemInfo.displayInfo() and .appWindowSize() incorrectly return width and height in units of physical pixels, rather than scaled pixels.  

On Mac, those functions correctly return scaled pixels, allowing plugins to properly size controls and dialogs.

Most recently tested on LR 11.1 / Mac OS 11.6.2 and Windows 10.

[This bug report is an updated version of the original posted in 2018, which never got copied to this forum:

https://feedback-readonly.photoshop.com/conversations/lightroom-classic/lightroom-lrsysteminfodispla... 

It has been edited somewhat to reflect changes in LR in the past four years.]

Details

On Mac, you can set a scaling factor for Retina displays via System Preferences > Displays.  Setting a scaling factor of 200% doubles the size of LR's user-interface elements.  On Windows, the user scales the user-interface elements via Preferences > Interface > Font Size; e.g. Font Size: Larger - 200% doubles the size. (The Windows display scaling affects just the menu bar.)

A number of LrView controls have width and height properties that are specified in units of scaled pixels. Scaled pixels times the scaling factor gives the number of physical pixels.

On Mac, LrSystemInfo.displayInfo() and .appWindowSize() return screen and window sizes in units of scaled pixels. This enables plugins to make a dialog as large as possible while still fitting on the screen; for example, the plugin can set the width and height of a scrolled_view() (in units of scaled pixels) to be somewhat less than the screen size (in units of scaled pixels).

But on Windows, LrSystemInfo.displayInfo() and .appWindowSize() return sizes in units of physical pixels, and there is no easy way for a plugin to get the current scaling factor to translate them to scaled pixels. This makes it impossible for a plugin to make a large window that is guaranteed to fit on the screen.

A Fix that Maintains Backward Compatibility

Correcting this bug would break existing plugins that rely on the incorrect return values from displayInfo() and appWindowSize().  Two trivial alternatives would maintain compatibility but allow plugins to properly size large windows:

- Change displayInfo() to also return fields "widthScaled" and "heightScaled", with width and height in scaled pixels. Add a new function LrSystemInfo.appWindowSizeScaled() that returns the width and height of the window in scaled pixels.

- Add LrApplication.fontSize(), which returns a number representing LR's scale factor set in Preferences > Interface > Font Size (e.g. 1.0 for "small", 2.0 for "Larger - 200%").  On Mac, plugins would ignore that, but on Windows, plugins would use it to compute the screen and app window dimensions in scaled pixels.

Demonstrating the Bug

The script below tries to create a scrolled_view() whose height is 1/2 of the screen height. On Mac, that works properly regardless of the current scaling factor, since both LrView and LrSystemInfo use the same units, scaled pixels. But on Windows, when Font Size is Larger - 200%, then the scrolled_view() is twice as large as it should be, overflowing the screen, because LrView uses scaled pixels and LrSystemInfo uses physical pixels.

local LrDialogs = import "LrDialogs"
local LrSystemInfo = import "LrSystemInfo"
local LrView = import "LrView"

local f = LrView.osFactory()
local format = string.format

local display
for _, info in ipairs (LrSystemInfo.displayInfo ()) do 
    if info.hasAppMain then display = info end
    end
local app = {LrSystemInfo.appWindowSize ()}

local width, height = 250, math.floor (display.height * 0.5)

local contents = 
    format ("Screen: %d x %d\n", display.width, display.height) ..
    format ("Lightroom window: %d x %d\n", app [1], app [2]) ..
    format ("scrolled_view should be: %d x %d\n", width, height) 

for i = 4, 100 do contents = contents .. format ("Line %d\n", i) end

local result = LrDialogs.presentModalDialog {title = "Scaling Bug", 
    contents = f:scrolled_view {width = width, height = height,
        f:static_text {title = contents}}}

[Rikk Flohr: Photography]

Setting status - adding bug number

[martinl68902366]

Hey John, 

Did you have any news about this bug ? 
I have currently the issue for publish service. 
When I try to create a collection setting view, it's hard to know which Height can I use. 

It's already different from new collection to the edit one. But it's hard to optimize it regarding the resolution of the screen. 

Did you find a workaround? 

I currently set the height with static number like this : 
if newCollection then
maxHeight = WindowsHeight - 350
else
maxHeight = WindowsHeight - 225
end

But that's not very cool.

[johnrellis]

If the bug's status changes, Adobe will post an update here. I think it's very unlikely they'll ever fix this bug, though.

I use the following hack workaround to get the scale factor on Windows:

--[[----------------------------------------------------------------------------
public number
windowsFontScale ()

Returns the scale factor for the currently selected font size in Preferences:

Small:          1.0
Medium:         1.0
Large (150%):   1.5
Large (200%):   2.0,
Large (250%):   2.5

Reads the preferences file to get the current setting. Returns 1.0 if 
the file can't be read or doesn't contain the setting.
------------------------------------------------------------------------------]]

function Util.windowsFontScale ()
    local prefs = child (getStandardFilePath ("appPrefs"), 
        "Lightroom Classic CC 7 Preferences.agprefs")
    local success, contents = pcall (LrFileUtils.readFile, prefs)
    if not success then return 1 end 

    local scale = contents:match ('AgPanel_baseFontSize = "([^"]*)"')
    if not scale then 
        Debug.logn ("Couldn't read AgPanel_baseFontSize", prefs, contents)
        return 1 
        end

    if scale == "medium" or scale == "large" then return 1 end 
    if scale:sub (1, 5) ~= "scale" then 
        Debug.logn ("Unexpected AgPanel_baseFontSize", prefs, scale)
        return 1 
        end
    local n = tonumber (scale:sub (6))
    if not n or n < 100 then 
        Debug.logn ("Unexpected AgPanel_baseFontSize", prefs, scale)
        return 1 
        end
    return n / 100 
    end