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

[Alessandro Sangiuliano]

Hi Fred,

yes this _NET_REQUEST_FRAME_EXTENTS is going to be problematic, i just looked at awesome and echinus code again, they have no support for it and GS Apps are working really fine with them.

I'm going to remove it as soon as I can and see what happens with a debbugging session after the map request. I also noticed that the App Icon is not mapped, but this is another story...

About the comment you posted:

NO! I didn't see it or I saw it and forgot about it! This could be a key one for solving the problem... that clirifies a lot of things.

About the data: ask whetever you want about the data I will provide them.

Thank you for the help,

Cheers Alex.

---

Da: Fred Kiefer <fredkiefer@gmx.de>
Inviato: lunedì 14 settembre 2020 21:15
A: Alessandro Sangiuliano <alex22_7@hotmail.com>
Cc: discuss-gnustep@gnu.org <discuss-gnustep@gnu.org>
Oggetto: Re: A window manager written in objective-c: uroswm and gnustep support problems

 

HI Alex,

even after reading your Github column, I still don’t quite understand the issue.

It might help you to know that all other window managers I am aware of don’t support the EWMH feature _NET_REQUEST_FRAME_EXTENTS, or at least none did when we implemented this feature. So this code path is lesser used in GNustep and there might be undetected issues with it. Maybe it would be best wo disable this feature in your window manager for now and to try to get the rest working first?


As for the configure event you should run the GNUstep application with the option „—GNU-Debug=NSEvent“ to see more information about event handling.
And did you see this comment in the GNUstep code:


          /*
            According to the ICCCM, coordinates in synthetic events
            (ie. non-zero send_event) are in root space, while coordinates
            in real events are in the parent window's space. The parent
            window might be some window manager window, so we can't
            directly use those coordinates.
            Thus, if the event is real, we use XTranslateCoordinates to
            get the root space coordinates.
            */

This might be the reason why your events get handled incorrectly by the GNUstep code? But this is only guessing and won’t help. Without more data I won’t be able to help you.

Cheers,
Fred

> Am 14.09.2020 um 19:37 schrieb Alessandro Sangiuliano <alex22_7@hotmail.com>:
>
> 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.