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. The real value, in my opinion, of a GNUstep based WM is the ability to easily communicate using common protocols. 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 <[email protected]> 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:* [email protected] <[email protected]> > *Inviato:* venerdì 4 settembre 2020 12:04 > *A:* Fred Kiefer <[email protected]> > *Cc:* [email protected] <[email protected]> > *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 < > [email protected]>: > > 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
