Hello Friends, Currently, it seems that [NSWindow setFrame:…] doesn't take screen scale into effect. I think this can be addressed, but it is going to take a lot of team work.
For the purposes of this pitch, I am using the word 'points' to refer to the a pixel or group of pixels as described by the screens scale. (e.g if the scale is 2, then one point is 2 pixels wide. If the sale is 1, then one point is 1 pixel wide. Form the API user's perspective, I think that when setting the frame (in all the [NSWindow setFrame…] methods) and retrieving the [NSWindow frame] it should be in points, rather than pixels. Problem: Currently when you set [NSWindow setFrame:], the frame is in pixels instead of points, where as the internal geometry of the window is set up so it is always in points. This is only a problem when ScaleFactor != 1. So if you know that the internal geometry will need 600 points, you need to make sure you set the frame to 1200 pixels. A problem arises when you have hard-coded frames either in strings or in code. You have to make sure every time that you first scale the NSRect you want to use to the right point density before applying the frame. In many areas of the API, this doesn't happen either because the API hard coded the frame or because the frame comes form a string that is stored in a PLIST/GORM before or after the screen was scaled. Because the string is in pixels instead of points, the frame will be incorrect. This is the case with, for example, the Inspector in GWorkspace. Argument: The API user shouldn't have to do the math before setting the NSWindow's frame, and hard coded strings or NSRects should just work. The screen drawing space and the windows internal drawing space should match. Just like NSView NSWindow's setFrame should be considered in the same coördinate scale. [NSWindow frame] should return points [NSScreen size] should also return points Solution (1) If you set the frame with NSRect(0,0,300,200) but the point density is 2 pixels/point, the setFrame: methods will convert it to NSRect(0,0,600,200). And when you get back the frame, it will again scale it back to NSRect(0,0,300,200). This would make taking strings form plists that store the size of the window backwards compatible. It would also make it so when setting the window frame, you will use the same coordinate scale as the internal geometry of the window. Solution (2) Ensure that every NSRect you put into [NSWindow setFrame:] is scaled accordingly. This is an impossible task, because many GNUStep developers, aren't using a ScaleFactor that isn't one. Solutions (3) Add methods [NSWindow setFrameInPoints:] and [NSWindow setFrameOriginInPoints:] Study: Not So Easy I have tried to go and change [NSWindow _applyFrame] and [NSWindow frame] to do the transformation, but it seems like a lot of assumptions are being made about the frame of the window. For example, in NSMenuPanel, NSEvent, GSTitleView to name a few assume the screen coordinates to be in pixels.
