Re: A window manager written in objective-c: uroswm and gnustep support problems

[H. Nikolaus Schaller]

> Am 14.09.2020 um 21:38 schrieb Gregory Casamento <greg.casamento@gmail.com>:
> 
> 
> I don't know if you guys will consider this off-topic, but I feel compelled 
> to offer the following information:
> 
> On OPENSTEP and NeXTSTEP before it, there was no need for a window manager.  
> NSWindow knows how to draw itself, including its decorations/border/etc.  The 
> need for window managers grew out of X's original implementation where 
> windows were just boxes without decorations.

That is the way mySTEP is working. No window manager needed. There is one 
situation where a window-manager had benefits: if an application doesn't call 
its runloop you can't move or hide the window. IMHO even Cocoa has something 
built into the display server to handle this situation.

>  The real value, in my opinion, of a GNUstep based WM is the ability to 
> easily communicate using common protocols.

...and get non-GNUstep applications under control... Thinking of harmonized 
(themed) decoration for e.g. Firefox.

> 
> I realize this is not directly related to solving the problem mentioned, but 
> I thought I would chime in.
> 
> Thanks, GC
> 
> 
> On Mon, Sep 14, 2020 at 1:52 PM Alessandro Sangiuliano <alex22_7@hotmail.com> 
> wrote:
> Hello guys, I'm still here with this problem. It is going to be tricky.
> 
> This time I have more informations;
> 
> I started to use the github projects and columns feature so I can clean ideas 
> in my mind and put all toghether.
> 
> At this column called GNUstep support
> 
> https://github.com/AlessandroSangiuliano/XcbKit/projects/2#column-10827552
> 
> i wrote in a better way the problem, but with some additional informations 
> about is going to happen after a debbugging session.
> 
> I noticed that the map just works, the client window of a GNUStep is mapped 
> where I want to be apped inside the frame window at coordinates (0, 21).
> 
> The problem happens after the map request event, in the configure window 
> request event. In the coulmn is well described.
> 
> Do you think that resetting the W;_NORMAL_HINTS of the client window will fix 
> the problem?
> 
> I don't see how to fix the offset calculation that GNUStep does.
> 
> I tried to run GNUStep Apps with window managers that are going to be really 
> poor in ICCCM and EWMH support; I tried with twm and echinus ( a dwm fork); 
> With these GNUstep Apps are positioned inside the frame in the correct way 
> (echinus is a reparenting wm).
> 
> The source code of echinus is really few lines of code, I give it a flash 
> lookm it doesn't seem that play so much with offset or whethever. I'm just 
> failing something.
> 
> GNUStep Apps are working quite well also with awesome wm, I wm that i studied 
> to get some knowledge about xcb. The have totally no support for 
> _NET_REQUEST_FRAME_EXTENTS, while they update the _NET_FRAME_EXTENTS to the 
> window. 
> 
> I do that too, putting  the array as {3,3,21,3}. These values actually are my 
> borders + the title bar window (21 in height).
> 
> I also tried to use xprop on SystemPreferences running on my desktopn 
> environment, XFCE on Manjaro, the _NET_FRAME_EXTENTS are set to {2,2,28,2}. 
> 28 is the height of the title bar window, indeed is slighty heghter than mine.
> 
> Thank you.
> 
> 
> Cheers,
> Alex.
> Da: alex22_7@hotmail.com <alex22_7@hotmail.com>
> Inviato: venerdì 4 settembre 2020 12:04
> A: Fred Kiefer <fredkiefer@gmx.de>
> Cc: discuss-gnustep@gnu.org <discuss-gnustep@gnu.org>
> Oggetto: Re: A window manager written in objective-c: uroswm and gnustep 
> support problems
>  
> Hello,
> 
> 
> 
> 
> 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:
> 
> https://github.com/gnustep/libs-back/blob/master/Source/x11/XGServerWindow.m#L806
> 
> 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
> 
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store