Re: [proposed patch] GORM and hi-dpi

[Fred Kiefer]

> Am 05.02.2017 um 22:33 schrieb Graham Lee <address@hidden>:
> 
> Hi Fred,
> 
> thanks for giving feedback.
> 
> On 05/02/17 19:15, Fred Kiefer wrote:
>> I think this patch is wrong and any similar patches for the other panels 
>> wouldn’t help. The method userSpaceScaleFactor was added by Eric six years 
>> ago and it should work automatically without any specific adjustments in the 
>> application code. Could you please explain what is the issue here and how 
>> your patch tries to address it?
> 
> What I see is that when GORM is scaled up, it correctly scales the views in 
> the palettes but truncates them due to not drawing them into a large enough 
> space. I've attached a screenshot showing the current behaviour.
> 
> The patch I attached scales the content view into which GORM is drawing the 
> palette views, and fixes the bug as it appears in the screenshot.

Does this mean your patch scales down the content view?

>> Gorm here calls NSWindow initWithContentRect: and this should internally 
>> call frameRectForContentRect:styleMask: on GSWindowDecorationView and this 
>> should make just the adjustments your code is trying to make. The only issue 
>> I see there is that this code is using the scaling of the main screen. This 
>> will go wring if there are multiple screens with different scaling. If this 
>> is your problem we should address it in this class.
>> 
> Thanks, I saw that it was calling -initWithContentRect: and that this was 
> doing the correct thing with respect to scaling other windows (further, I saw 
> that if I modified this method, then other windows including standard 
> framework things like alert panels would be drawn incorrectly). So the 
> problem is presumably specifically down to how GORM is drawing its palettes, 
> which is why I made the change where I did.
> 
> What I see in GormCore is that the views added to this window's contentView 
> are actually removed from it and added as subviews of a different view, in 
> -[GormPaletteManager setCurrentPalette:]. It may be that the scaling is going 
> wrong here, but again I do not see why that would be so.

Shouldn’t we try to fix the issue when the views get moved into the 
GormPaletteManager? Is that window actually scaled up big enough? It could be 
that Gorm is actually creation a window with an explicit frame. Or we did 
forget to handle the scaling in the constrain methods of NSWindow? This seems 
like the most probable cause. I need to check this.

Fred