discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I: A window manager written in objective-c: uroswm and gnustep suppo


From: Gustavo Tavares
Subject: Re: I: A window manager written in objective-c: uroswm and gnustep support problems
Date: Mon, 14 Sep 2020 23:15:32 -0400
User-agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3

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 <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.

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:


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:


Where map requests are handled:



Where client messages are handled:



Where the support for EWMH is going to be implemented:


Same for ICCCM:



<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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]