[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A window manager written in objective-c: uroswm and gnustep support
From: |
H. Nikolaus Schaller |
Subject: |
Re: A window manager written in objective-c: uroswm and gnustep support problems |
Date: |
Mon, 14 Sep 2020 22:20:27 +0200 |
> 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