Re: [proposed patch] GORM and hi-dpi
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? 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. Hope this helps, Fred > Am 05.02.2017 um 16:49 schrieb Graham Lee : > > [sorry, I sent this to bug-gnustep, then was told that this was a better > forum...] > > From: Graham Lee > To: > Sent: 2/5/2017 12:27 PM > Subject: [proposed patch] GORM and hi-dpi > > Hi folks, > > GORM does not draw its palette views correctly when the display scale > factor is anything other than 1.0. Well, what I actually think is that > each palette does not create its own content view correctly, but that > means a different patch per palette. > > I worked with Steven Baker here at FOSDEM to patch it, and the > per-palette patch looks like the attached file. I'd like to discuss > whether writing this patch another four times for the other palettes is > appropriate, or whether there's a preferable alternative to do this. > > Cheers, > > Graham. > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [proposed patch] GORM and hi-dpi
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. 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. Thanks for your help, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [proposed patch] GORM and hi-dpi
> Am 05.02.2017 um 22:33 schrieb Graham Lee : > > 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
