For those of you following, the bug that I was noticing that was causing 
certain windows to load at the wrong size, is now fixed on my 
improved-screen-maths branch. It was just due to our overlooking setMinSize and 
setMaxSize on NSWindow. I simply needed to ensure that I sent pixel sizes to 
back. 

NOTE: This bug is currently in the OFFICIAL GWorkspace using the OFFICIAL 
libs-gui because of the assumptions that developers make/overlook when sending 
metrics to back (e.g pixels rather than points). Again, my changes fix this so 
one no longer matters about pixels vs points. And since it appears that in 
almost all instances developers were assuming that back would take care of 
this, they never bothered to multiply. The impacts of my changes should be 
minimal and in-fact fix a lot of exiting bugs when using a GSScaleFactor other 
than 1.

You can view my adjustments to both libs-back, libs-gui below. 

(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

I want to also note that the solutions I implemented solved a lot of the issues 
related to GSScaleFactor in other apps like GWorkspace that were loading 
windows at incorrect sizes, the desktop at the wrong size. Or windows having 
their content shifted. 

If y'all notice any other GSScaleFactor bugs, please let me know. I am very 
motivated to get all those bugs squashed. 

> On Sep 8, 2023, at 11:27 PM, dr_c...@me.com wrote:
> 
> Thanks for checking. I'm sure I fixed it with out noticing as I was going 
> along. I appreciate your taking the time. 
> 
> A question for those who are familiar with the Wayland backend. Firstly, 
> making the changes for Wayland, was easy. I only had to adjust the NSEvent 
> call sites there as well. But I did this under the assumption that Wayland 
> presents window surfaces the same way X11 did, in pixels instead of points. 
> Is this assumption still correct? If so, then I did the Wayland changes as 
> well. Really quick job. 
> 
> I haven't tested it yet as I don't have a VM set up for it. 
> 
> Over the last few days I have been continuing to test the changes I made in 
> my fork, and they work great. I am still trying to solve the issue with some 
> windows being 1/2 the size in both directions. If anyone has any insights 
> there, I would appreciate it!
> 
> Thanks!
> 
>> On Sep 7, 2023, at 2:46 AM, Fred Kiefer <fredkie...@gmx.de> wrote:
>> 
>> 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!
>>>>>> 
>>>>> 
>>> 
> 

Reply via email to