|
Hi Gregory, (I'm sorry Greg I forgot to CCs this email, sorry for the duplicate)
yes know that GNUstep can handle windowing and decoration by itself fo GNUstep based Apps, but it can't handle other toolkit apps.
I need a WM that is capable to handle GNUstep Apps, gtks apps, qt apps or more in generale EWMH/ICCCM Apps/toolkits. My WM has the priority to support GNUstep based Apps and to provide the best integration with a Desktop Environment; it should handle a GS App
while it is handling for exemple a java App like CLion/Intellij and/or a gtk app and so on.
Actually there aren't major window managers that integrates well with GNUstep, the only one is WindowMaker, but I don't like it, how it works, its interfaces etc etc. I'm not saying that wmaker is bad, I'm just saying i don't like it.
For example the new gnome3 wm, mutter or how they recalled it, draws the GS menus behind the gnome system bar making them really hard to interact with, or without loosing a lot of time in crazy hacks configurations. AwesomeWM sometime reparent GS icon Apps
with a frame window and a title bar (maybe it was missing the override-redirect check and now they fixed it?)
>From the system i'm writing, manjaro+xfce, the Wm draws th GS App Icon behind the bottom bar, making it annoying all the time to move it here and there.
My project is not to write another useless window manager, i want to implement a full DE and window manager is the first step. A DE based and written with GNUstep, that gives priority to GNUstep full integration with the DE but able to use other toolkits apps.
Well, is not true that the WM is the first step, actually is the second one, the first was the rik.theme, indeed when the uroswm will reach a good status I will fix some rik.theme code for libobjc2 v2.
My DE is not going to invent something of new, just gives easy to use, confortable, well know user interface (see os x), make easy as much as possible all kind of configurations and so on.
I'm following on github the guys of NeXTSpace, they are doing a great work, but it is a NeXTStep like DE interface, and you know what i think about NeXT Interfaces, they were really good and elegants at the times, but todays I won't use them.
The nice of the open/free source is this, maybe a day we can choose between NEXTSpace for the lovers of the NEXT interfeces, and another DE, that actually has no name, for the lovers of modern interfaces.
Maybe a great collaboration could born too, but is soon to talk about that.
My goal is to write a good kit for xcb in objective-c, and on that I'm writing the window manager, so that we can use the kit for other purpose too in the future.
So toolkits interopability is why i'm not using -gui in XCBKit but only -base + xcb (and some its utilities library) + cairo. Also, if i would -gui in XCBKit i would mix indirectly xcb calls with Xlib calls -back is using Xlib, I'm speding a lot of time reading
at some -back classes like I spent at the beggining a lot of time on the awesome code that helped me a lot to understand better the bad documented xcb.
Any help is appreciated, also just opinions, discussions and exchange of ideas.
Thank you,
Alex
Da: Gregory Casamento <greg.casamento@gmail.com>
Inviato: lunedì 14 settembre 2020 19:42
A: Alessandro Sangiuliano <alex22_7@hotmail.com>
Cc: Fred Kiefer <fredkiefer@gmx.de>; discuss-gnustep@gnu.org <discuss-gnustep@gnu.org>
Oggetto: Re: I: A window manager written in objective-c: uroswm and gnustep support problems
Additionally, it's important to remember that GNUstep can operate in that mode as well via setting GSBackHandlesWindowDecorations to YES via defaults. This setting causes GNUstep to draw
its own windows fully and without the need for a WM.
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
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.
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
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
--
--
|