I couldn't send the email for the values in the previous days, I was away for a little vacation.
These are the values and control flow:
At the time of the ap request uroswm maps to (0,21) the client window in the frame, where 21 is the actual size of the title bar.
uroswm output:
Client window decorated with id 4194378
2020-09-04 12:08:48.584 uroswm[4358:4358] Window id: 4194378. Parent window id: 2097169.
Window Position: (x: 0, y: 21), Size: (width: 592, height: 414)
2020-09-04 12:08:48.584 uroswm[4358:4358] Window id: 2097169. Parent window id: 970.
Window Position: (x: 200, y: 286), Size: (width: 593, height: 436)
The window with id 2097169 is the frame window.
SystemPrederences output:
2020-09-04 12:08:48.542 SystemPreferences[4359:4359] Ignore left offset change from 0 to 3
2020-09-04 12:08:48.543 SystemPreferences[4359:4359] Ignore right offset change from 0 to 4
2020-09-04 12:08:48.543 SystemPreferences[4359:4359] Ignore top offset change from 0 to 24
2020-09-04 12:08:48.543 SystemPreferences[4359:4359] Ignore bottom offset change from 0 to 3
2020-09-04 12:08:48.543 SystemPreferences[4359:4359] Reparent was with offset 0 21
2020-09-04 12:08:48.543 SystemPreferences[4359:4359] Parent border,width,height 3,65,85
2020-09-04 12:08:48.597 SystemPreferences[4359:4359] Ignore right offset change from 3 to 4
2020-09-04 12:08:48.597 SystemPreferences[4359:4359] Ignore top offset change from 3 to 24
2020-09-04 12:08:48.597 SystemPreferences[4359:4359] Ignore bottom offset change from 3 to 4
2020-09-04 12:08:48.597 SystemPreferences[4359:4359] Reparent was with offset 0 21
2020-09-04 12:08:48.597 SystemPreferences[4359:4359] Parent border,width,height 3,593,436
Despute the ignore logs I'd like to solve (but actually I don't know the -back code about that), SystemPreferences is printing a (0,21) reparenting offset that is correct.
All this is happening in the handleMapRequest uroswm's method/message. The border that is 3 is correct too.
So the uroswm maps it and then receive a configureNotify and here I noticed this:
2020-09-04 12:08:48.586 uroswm[4358:4358] Configure notify for window 4194378
2020-09-04 12:08:48.586 uroswm[4358:4358] In configure notify for window 4194378: 200, 302
So logging the event it says that the client window 4194378 that is already reparented to the frame 2097169 is configuring to (200,302). We can call this Delta! It is just the frame window offset, plus some pixel for the y coordinate, relative to the root window (x,y) (root window id:907)
So I can say this:
the frame window is mapped relative to the root window at position (200,286);
the client window is mapped relative to the frame window at the same position, plus some pixels (probably coming from the titlebar calculations) , so -back is reconfiguring the client window inside the frame at the same distance of the frame to the root window.
So we know that the top left corner of the root window is (0,0) and the frame is mapping to (200,286). The client window takes somewhere those values, does some calculation, and reconfigure the position in the frame to the same distance that the frame has to the root window's top left corner, while it should just be (0,21) like it is after the mapRequest event. So for what I saw it is the configure notify event that is going wrong.
I can suppose that after the map request, and the mapping, -back is trying to calculate the offset, but I don't know how. In -back code i can see it is getting the extents in the right way and that are correct, but before that there is a generi ofset calculation that I don't know where -back is doing it.
Message -checkStyle line 806:
Ideally after the map request, receiving the configureNotify, I'd like to have (0,21) from the event->x and event->y
Code from XCBKit still not pushed. In map request this is the snippet that prints the values of the positions and so on both for frame and window, here is where the client i mapped inside the frame at (0,21):
[self mapWindow:frame];
[frame decorateClientWindow];
NSLog(@"Client window decorated with id %u", [window window]);
[window description];
[frame description];
Snippet in the configureNotify event where I get the (200, 302) for the client window in the frame window after mapped.
XCBWindow *window = [self windowForXCBId:anEvent->window];
NSLog(@"In configure notify for window %u: %d, %d", anEvent->window, anEvent->x, anEvent->y);
XCBFrame *frame;
XCBWindow *clientWindow;
At that time we try to determine how big the window borders are going to be and these values will be used later on to compute the internal offset for all GNUstep windows.
Hope this helps,
Fred
Am 18.08.2020 um 18:21 schrieb Alessandro Sangiuliano <alex22_7@hotmail.com>:
Hello everyone, is a lot I'm not writing here due of the work i was doing I had no time to code with gnustep, however now I'm back and some months ago I took again my project, the window manager.
To be honest, I'm writing a kit to code window managers, XCBKit and as the name says it is on top of xcb. I was insipred by the étolié XCBKit for some things, but it works in a different way. However my XCBKit will have some usefull code from the étoilé one escpecially the composite support, but is actually really soon talking about compositing.
Actually the status of the kit + the window manager uroswm, is good but a lot of work is needed. Indeed the version is 0.0.10.
Fred helped me privately when something was not clear, the code was too young and really bad to start to talk here. Actually is a bit better but still bad (well not really bad, is a progress!).
The wm is able to handle gtk application in a good way, I can frame them iconify them, moving resizing, closing via WM_DELETE_WINDOW etc etc.
The wm is going to be, slowly, EWMH compliant and ICCCM too where needed.
I started to write it on my old mac laptop with 10.9.5 and XCode 5, as Fred saw time ago in a video I shared with him. When I reached some goals I had to complete, I started the linux port on gnustep and this was really great because I HAD TO CHANGE NO LINES OF CODE!
I literally had just to write the GNUmakefile start the build and all was built and working, in less than 1 hour I had the port complete, so CONGRATULATIONS to all GNUstep developers and contribs. I remeber some year ago when I started with GNUstep porting simple apps form OSX to GNUstep needed some code changes and I was expecting te same for uroswm.
So, it's time to talk about some problems I'm having to get a god support for gnustep apps.
Actually when I reparent a gnustep app in my frame the position is not what I'm expecting, in the zip archive I attached you can see what I mean.
As you can see I have no problems with the calculator and google chrome, while for SystemPreferences (and other gnustep apps) I ever get the app on the shifted on the right or right-bottom.
I'm pretty sure I'm not supporting some EWMH/ICCCM standard that gnustep is using or asking to the window manager. For what I saw gnustep is strongly supporting these stadards.
Do you have some ideas about this?
The branch you should look and where the developing is going is:
https://github.com/AlessandroSangiuliano/XcbKit/tree/feature/gnustep_support
Where map requests are handled:
https://github.com/AlessandroSangiuliano/XcbKit/blob/feature/gnustep_support/XCBKit/XCBConnection.m#L444
Where client messages are handled:
https://github.com/AlessandroSangiuliano/XcbKit/blob/feature/gnustep_support/XCBKit/XCBConnection.m#L895
Where the support for EWMH is going to be implemented:
https://github.com/AlessandroSangiuliano/XcbKit/blob/master/XCBKit/services/EWMHService.m
Same for ICCCM:
https://github.com/AlessandroSangiuliano/XcbKit/blob/master/XCBKit/services/ICCCMService.m
<gnustepSupport.png.zip>
Cheers,
Alex