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 <gra...@iamleeg.com>: > > [sorry, I sent this to bug-gnustep, then was told that this was a better > forum...] > > From: Graham Lee <gra...@iamleeg.com> > To: <bug-gnus...@gnu.org> > 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. > > <gorm-palette-scale.patch>_______________________________________________ > 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