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

[Svetlana Tkachenko]

Dear Alessandro,

> So, it's time to talk about some problems I'm having to get a god support for gnustep apps.
> 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.

Odd. How to install this software and test it out?

Regards,
Svetlana

[Alessandro Sangiuliano]

Hello,

you need to install XCBKit and uroswm here:

https://github.com/AlessandroSangiuliano/uroswm

In the README file there are some installation and testing instructions.

There are no configuration steps.

You just clone the XCBKit and uroswm, install the dependencies suggested in the uroswm README file, then you install XCBKit and uroswm.

$: make

$: (sudo/su) make install

Despite the code grown really fast, however don't expect to use it as production window manager, it is too young and needs some work and EWMH ICCCM standards support. Actually has no cursor support so you will work all the time with the X11 "X" pointer.

When I'll have a good status in gnustep supporting, I will do a lot of code cleaning, probably a second rework.

Each distribution could have renamed the libraries slighty different, on ubuntu we are talking about libxcb, on manjaro (ARCH Linux) we are talking about xcb. You need to install the -dev counterparts for each library too.

Have fun,

Alex.

---

Da: Svetlana Tkachenko <svet...@members.fsf.org>
Inviato: sabato 22 agosto 2020 23:44
A: Alessandro Sangiuliano <alex...@hotmail.com>
Cc: discuss...@gnu.org <discuss...@gnu.org>
Oggetto: Re: A window manager written in objective-c: uroswm and gnustep support problems

 

[Fred Kiefer]

Hi Alessandor,

from looking at your image I would expect that the GNUstep application, in this case System preferences, is expecting the wrong offset from the window manager. Here it would help to see which values get displayed when the first GNUstep application for your window manager starts up. 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 <alex...@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>

[Alessandro Sangiuliano]

Hello Fred,

from looking at your image I would expect that the GNUstep application, in this case System preferences, is expecting the wrong offset from the window manager. Here it would help to see which values get displayed when the first GNUstep application for your window manager starts up

3 weeks ago, more or less, I added the _NET_FRAME_EXTENTS standard support. I saw in the -back code gnustep is searching for it. I got some result with that but still missing something. The documentation on the EWMH is a bit confusing; it says I should add the _NET_FRAME_EXTENTS to the window's frame, but when -back is asking for the window is still not mapped so I should do an estimation but actually I know that the borders left, right, top and bottom are all 3.

From the EWMH doc:

_NET_FRAME_EXTENTS

_NET_FRAME_EXTENTS, left, right, top, bottom, CARDINAL[4]/32

The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the window's frame. left, right, top and bottom are widths of the respective borders added by the Window Manager.

-back is doing a _NET_REQUEST_FRAME_EXTENTS and I added the support for this and following the control flow with gdb SytemPreferences it is entering the 'if' checks where the request got supported by the WM. However the doc is saying now that I should add the extents to the window (and not the frame):

From the doc:

A Client whose window has not yet been mapped can request of the Window Manager an estimate of the frame extents it will be given upon mapping. To retrieve such an estimate, the Client MUST send a _NET_REQUEST_FRAME_EXTENTS message to the root window. The Window Manager MUST respond by estimating the prospective frame extents and setting the window's _NET_FRAME_EXTENTS property accordingly. The Client MUST handle the resulting _NET_FRAME_EXTENTS PropertyNotify event. So that the Window Manager has a good basis for estimation, the Client MUST set any window properties it intends to set before sending this message. The Client MUST be able to cope with imperfect estimates.

Rationale: A client cannot calculate the dimensions of its window's frame before the window is mapped, but some toolkits need this information. Asking the window manager for an estimate of the extents is a workable solution. The estimate may depend on the current theme, font sizes or other window properties. The client can track changes to the frame's dimensions by listening for _NET_FRAME_EXTENTS PropertyNotify events.

This is the case, because the client is still not mapped, so I add the extents both to the frame and the window in different moments. For this case all starts from the handling of a client message and a check to see if it is an EWMH request (for extents in this case), then I add to the window the extents; here the flow:

handleClientMessage in XCBConnection.m check for ewmh request:

https://github.com/AlessandroSangiuliano/XcbKit/blob/feature/gnustep_support/XCBKit/XCBConnection.m#L919

handleClientMessage in EWMhService.m, this class handle the messages coming from the EWMH standards:

https://github.com/AlessandroSangiuliano/XcbKit/blob/feature/gnustep_support/XCBKit/services/EWMHService.m#L598

Here is where I add the extents to the window and not the frame as the EWMH _NET_REQUEST_FRAME_EXTENTS is saying to do.

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.

What values do you want to see? I can log them all.

Da: Fred Kiefer <fredk...@gmx.de>

Inviato: domenica 23 agosto 2020 21:25

A: Alessandro Sangiuliano <alex...@hotmail.com>

Cc: discuss...@gnu.org <discuss...@gnu.org>

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

 

Cheers,

Alex.