It is gone now, maybe I was looking at an old version of the code? In the git history you can still see it on line 546.
On the road > Am 07.09.2023 um 01:38 schrieb dr_c...@me.com: > > So I read the code again, and I just wasn't able to find where I was > dividing twice. I set a rule that I only preformed division at the NSEvent > construction site (to ensure that all the math that happens up until that > point was surly in pixels. Would you mind showing me the line. I assume it > it's in XGServerEvent.m. I might just be tired, or I confused myself. Thanks! > >> On Sep 6, 2023, at 3:37 AM, Fred Kiefer <fredkie...@gmx.de> wrote: >> >> This looks a lot better, though I only looked at the back part. There are a >> few typos and at one place (mouse events) you are doing the division twice. >> >> Cheers, >> Fred >> >> On the road >> >>>> Am 06.09.2023 um 04:31 schrieb dr_c...@me.com: >>>> >>> Hello All, >>> >>> I just finished rebasing my code on the current libs-gui and libs-back and >>> cleaning it up so it follows the current indentation conventions for >>> GNUStep. I compiled it, and it all works (except for one bug that I am >>> trying to track down that may be unrelated). The links below should work >>> with the better re-based code. >>> >>> (1) libs-back >>> https://github.com/austintatiousness/libs-back/tree/improved-screen-maths >>> (2) libs-gui >>> https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths >>> >>> Bug: >>> There is one bug that I am still trying to track down that I believe is >>> from GORM files or deferred windows. In a 2x scale factor, they display >>> still at half the height. No idea why. It might have to do with the order >>> the the screen gets attached to the window? Maybe they are deferred? >>> Something I notice was that when the affected windows are allocated and >>> first set up, the correct sizes are reported to libs-gui and libs-base (i >>> tracked this with a bunch of NSLogs), but at some points libs-base sends >>> another NSEvent with it half the size causing the window to resize to half >>> the size. Maybe there is a rect cached somewhere that it is using and math >>> is preformed on it to cut it in half. I just can't figure where the event >>> is originating form. >>> >>> Thanks for reading! >>> >>> >>> >>>> On Sep 5, 2023, at 9:17 AM, dr_c...@me.com wrote: >>>> >>>> You're not wrong it is currently messy code. I had tried so many different >>>> things before I fully understood the drawing system and the Back->GUI >>>> interactions. Though, I thought I did pull out all of the code that I used >>>> to mitigate the issue before as with my adjustments, they were no longer >>>> needed. It was a LOT of learning. I started on a copy that was a few weeks >>>> old, but I thought that I re-synced those changes in before I moved the >>>> code back in. May I didn't. >>>> >>>> So, what I will do is clone it again and add back each change so the code >>>> matches better and you can see the changes more clearly and try not to >>>> adjust any of the indentation. It might look like more changes were made >>>> when you do a code comparison because I had modified and changed back so >>>> many things and then back when I realized it wasn't needed. To be honest, >>>> in the end, it really ended up just being som minor changes in Back and >>>> changing how NSWindow adjusted the base decoration view and adding a new >>>> method to scale drawing. >>>> >>>> I will post an update soon to clean up some of the code to make the code >>>> comparison cleaner in both back and base. >>>> >>>> Thanks! >>>> >>>>> On Sep 5, 2023, at 3:37 AM, Fred Kiefer <fredkie...@gmx.de> wrote: >>>>> >>>>> I had a short look at your changes and sadly these don’t resemble the >>>>> clear idea you expressed in your mail. There are many leftovers from your >>>>> previous attempts to tackle the issue. You also missed out on the changes >>>>> that happened to GNUstep since you forked off your branch. A simple >>>>> rebase would help here. On the other hand, you are using an unmatched >>>>> indentation pattern and added plenty of empty newlines. Maybe it would be >>>>> best if you start anew from the current GNUstep code and just implement >>>>> your idea? >>>>> >>>>> Hope this helps, >>>>> Fred >>>>> >>>>> On the road >>>>> >>>>>> Am 05.09.2023 um 09:17 schrieb Fred Kiefer <fredkie...@gmx.de>: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> This approach sounds sensible to me. But as you said, it will take some >>>>>> more effort to spread it through the whole library, especially all the >>>>>> different backends. And there is also the case where GNUstep does the >>>>>> window decoration drawing. >>>>>> I am currently travelling and wont be able to review your code in detail >>>>>> before I am back home. But I will try to have a quick look to maybe >>>>>> point out some further difficulties. >>>>>> >>>>>> Cheers, >>>>>> Fred >>>>>> >>>>>> >>>>>> On the road >>>>>> >>>>>>> Am 05.09.2023 um 01:29 schrieb dr_c...@me.com: >>>>>>> >>>>>>> Hello Friends, >>>>>>> >>>>>>> As you may have read I have been working on getting some of the >>>>>>> ScreenFactor bugs squashed. One of my theories is that a lot of GNUStep >>>>>>> developers are assuming screen scaling of 1. This creates a problem >>>>>>> where the values coming in from NSEvent, NSScreen are in pixels and not >>>>>>> points. I noticed that apps like GWorkspace used the screen resolution >>>>>>> (in pixels) to generate its desktop and center its dock which cause the >>>>>>> dock and desktop items to disappear. Originally, I fixed this by going >>>>>>> in my version and dividing by the correct scale. I then noticed that >>>>>>> these little bugs were everywhere. I also noticed that sometimes the >>>>>>> NSString value of a NSRect saved to Plists were in pixels as well, >>>>>>> creating a problem when screen scaling would change. Suffices to say, I >>>>>>> wanted a fix that would allow all these other projects to display >>>>>>> correctly with out having to go to each one and divide by scale factor >>>>>>> for the offending views. >>>>>>> >>>>>>> There are two libraries that this affects (my version of the projects >>>>>>> are here) >>>>>>> (1) libs-back >>>>>>> https://github.com/austintatiousness/libs-back/tree/improved-screen-maths >>>>>>> (2) libs-gui >>>>>>> https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths >>>>>>> >>>>>>> To fix this, I proposed that we allow AppKit to assume that all >>>>>>> geometry is in points instead of pixels according to the screen the >>>>>>> window is on. This required only some minor changes actually. >>>>>>> >>>>>>> 1) When libs-back constructs NSEvents that pertain to an NSWindow, it >>>>>>> needs to ensure that all the math is scaled by the screen factor of >>>>>>> that window. >>>>>>> 2) When libs-gui sends data to back, back knows that it will be in >>>>>>> points and fixes it. >>>>>>> 3) NSWindow needed some minor changes to its drawing routines because >>>>>>> the assumption is no longer that that decoration view (_wv) is scaled, >>>>>>> but instead a theoretical layer just below it is. So no longer do we to >>>>>>> a transform on the view, but instead just do a transform right before >>>>>>> drawing. You will see a method added to NSView - (NSAffineTransform*) >>>>>>> _baseMatrixForDrawing , that handles the math for each view so they >>>>>>> draw at the correct scale. >>>>>>> >>>>>>> When I finished fixing all of this, some of the other changes that I >>>>>>> had previously proposed were no longer needed. >>>>>>> >>>>>>> Some caveats: In my tests, I only changed the X11 code, I am only using >>>>>>> frames drawn by GNUSteap instead of the window manager. >>>>>>> >>>>>>> I have compiled and tested the code against GNUStep Desktop, and it all >>>>>>> is working great. There are still a few bug fixes (I cannot figure out >>>>>>> why items loaded from gorm sometimes are divided by the screen factor), >>>>>>> but some of the issues I encountered in other apps are now fixed when I >>>>>>> change my screen resolution. >>>>>>> >>>>>>> I would really love it if my code could be reviewed and possibly taken >>>>>>> into consideration to being added to the official reposatory. >>>>>>> >>>>>>> As it is right now, I'm not going to be using an old monitor for my >>>>>>> work, and I am working on a Swift bridge so I can port some of my >>>>>>> software. I will be using my version of the frameworks for this project >>>>>>> because unfortunately, as the bugs currently are, my ports wouldn't >>>>>>> work correctly. >>>>>>> >>>>>>> Lastly, I am hoping that I copied all the code back into my repository, >>>>>>> please let me know know if something doesn't build. >>>>>>> >>>>>>> Thanks! >>>> >>> >
