Hey Greg! Thank you for the info. Replying to you because I find this makes me want to ask:
What’s the difference between a window manager and an NSWorkspace? Or how might they be related? https://developer.apple.com/documentation/appkit/nsworkspace?language=objc http://www.gnustep.org/resources/documentation/Developer/Gui/Reference/NSWorkspace.html To me, it seems like the communication protocol could fit in here. On Cocoa, NSWorkspace already has: @property(readonly, copy) NSArray<NSRunningApplication *> *runningApplications; NSApplication has an array of Windows. You could conceivably imagine a category method on NSWorkspace that could give you all the windows. - Then you could add styling that can be sent down from the workspace - Inagine something like NSWindowArrangement that can be launched from an NSWorkspace and will launch the apps saved to it as well. Would love to what you have in mind! On Mon, Sep 14, 2020, at 3:38 PM, Gregory Casamento wrote: > > 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 <alex2...@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:* alex2...@hotmail.com <alex2...@hotmail.com> >> *Inviato:* venerdì 4 settembre 2020 12:04 >> *A:* Fred Kiefer <fredkie...@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 >>> <alex2...@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
