The Wakefield committers may hold off-line discussions from time-to-time. Since these meetings are just for the committers and invited wayland experts, summary minutes will be recorded here as time permits
Online Zoom Meeting 9am PDT Jan 4th 2023
Attendees: Niels de Graef, Kevin Rushforth, Victor D'yakov, Alexey Ushakov, Alexander Zvegintsev
In December I did some testing regarding the "automated tests become manual on OL 9 because of confirmation for each screencapture".
How many user interactions (select display, click share screen button) are required to do this?
The answer is ~11k, so we are definitely not going to do this and will wait for the restore_token backport to 9.4.
Regarding not getting a displayChanged event after a setDisplayMode call:
On Ubuntu 22.04, we get a ConfigureNotify for the root window when we switch to a non-native resolution, but we don't get it when we switch back to the native resolution.
On Ubuntu 23.04 and 23.10 we get both notifications.
We are continuing our internal testing of Intellij Idea on JBR 21 + pure wayland prototype, so far so good. It is only software rendering for now, but for the IDE purposes it works pretty well.
Also, after our discussion with Phil,, we are rewriting our hardware accelerated code for Vulkan in C, it is less fun than it was before, but we are moving forward with this approach.
Alexey, when you mentioned the software rendering, did you get things working?
Yes, it works fine. We use Wayland surfaces, and our java2d C loops to render geometry and stuff like that, Marlin for anti-aliasing rendering. It is able to support all the features that we have in Idea.
The funny thing is that it works better than X11 code.
We want to launch internal and external preview with non-default Wayland toolkit, provide proper VM options for some people who want to test it.
We already have some people from our tracker who have built our branches and launched Idea.
Of course there are some missing features, for example, we don't have some special shaders for better text rendering, but grayscale antialiasing works quite well.
I suppose that most of the work was done by the Wayland server, we present the stuff and in the actual Idea we don't need to pass rendering with hardware acceleration.
Probably with some crazy animations it would suffer.
I didn't expect such positive surprises at the beginning of the year. If it is necessary, I can ask people from Fedora community to test it. But I do not know how far we are from that.
It is not in the main OpenJDK repository, we do some regular syncs with the wakefield repository. And yes, it would be interesting, but it will probably require some manual patching of the distribution you provide.
That's where RPM Fusion could come in, so if people want to test it, here's a random package you can install to see if it works for you, and if it doesn't you can go there and file a bug.
Sounds good, we can provide a current branch or prepare a special one in the wakefield for this purpose.
Online Zoom Meeting 9am PDT Dec 7th 2023
Attendees: Niels de Graef, Victor D'yakov, Alexey Ushakov, Philip Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev
I don't have much to share regarding Wakefield, just that the fix for not showing focusable popups has been pushed.
Recently Nikita asked about usage of C++ standary library in on Wakefield mainling list, I understand is not quite good for us. What about just C++? Hotspot use it.
I do not like C++ at all, hotspots themselves had consequnces it terms of they basically had to abandom supporting some OSes because of C++,
and the Solaris organization said that they deliberately never allowed any part of core solaris to be written in C++. It just takes away a problem if we just stick to C.
The question is whether we should use C heavily or just move to java where it is possible?
Yes, that sort of the architechture we've had in every other implementation of everything, it all lives in java then you just call native.
If we were to look at a long term future, we could use FFM. The idea there is that you write everything in java, and the native library just accessed throught FFM.
So writing it oriented around the native implementation, makes it a little bit harder to move to the FFM.
So I am not saying that you should adopt FFM for this, but you might want to think of it.
FFM is final as of JDK 22, I already pushed a small usage of it, but I have to jump through hoops. The biggest issue that we have that it needs some time to warm up.
The largest chunk of work that I did was to try to merry code in the Idea to the new reality of Wayland, some quirks that I asked on the mailing list,
when some window loses focus and it cannot know which one is going to get it.
The approach of waiting just a little bit for the other window to aquire focus works quite well(so far in a very limited context), but I am still trying things out.
We saw that the Red Hat Linux 10 is planning to drop the X.org and X11 session, do you know when Fedora is going to do so?
Since Fedora is a community project, it is up to the community to decide. Fedora can take many more packages, if they want they can have a Cinnamon or other sessions, but we will not have X.org in RHEL10.
I have a question regarding the OL/RHEL 9, Red Hat empasized stability, but the version of Gnome doesn't seem to support the restore token functionality that we make important use of it the screen capture code.
It was added in later version of Gnome, which did not make into 9, and it seems to be dooming us never be able to test Red Hat Linux 9 in X11 compatibility mode. If is definitely the case that they won't be ever upgrade Gnome in 9?
We usually keep packages the same, but we do backports when required. Specifically for the restore token I thought we solve this in 9.3(released few weeks ago). But if it isn't there you can always file a bug for that, and we can internally investigate it.
My advice would be to check the latest available.
Online Zoom Meeting 9am PDT Nov 9th 2023
Attendees: Niels de Graef, Victor D'yakov, Alexey Ushakov, Kevin Rushforth, Philip Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev
My old fix does not take into account that popup may be focusable(e.g. has TextField). I have a solution and will publish it soon. And we'need to backport it to JDK 21.
We are making a good progress so I will let Maxim give more details about on that, I am more focused on rendering, there is not much progress there.
Most of the progress was not in the wakefield framework, we started experimenting with running our IDEs using the pure Wayland toolkit, so far so good. I had to make quite a few modifications to the IDE code that relied on certain XToolkit related classes and made a lot of assumptions out of that. There are, of course, there are quite a few hiccups here and there.
For example, some of the popups just flash instead of showing themselves at a certain position on the screen, or pasting does not always work for some reason, it starts choking every 5 times. There are weird corner cases and I'll have to go through mostly the IDE code, rather than the toolkit code to iron them out before we go public with this.
It is still usable, performance wise feels about the same as XToolkit. Resource wise, it seems to consume slightly more memory, but I haven't spent too much time looking into that.
My main concern for me at this point is a window placement, and I was wondering if guys from RedHat might have some advice on that. I discovered that gnome has a kind of extension interface for Wayland, where you can set a modality for your window. It has a very nice effect on modal dialogs, it darkens the background, it does not allow to it does not allow the focus to be transferred to the parent window, it shows the dialog centered on top of the window that it is its parent, it is all very well, except that many of our windows are not really dialogs, although they act like ones. For example, the find window, it is not modal, it does not prevent you from focusing a window underneath it, and the problem for me, and I suspect for many users, is going to be that it always opens towards to the top left corner of the screen no matter where you opened it last time.
So I was wondering if there is any way to at least open the window in the same position it was opened before?
Is there anything else I can do, like give the window manager a hint that I want it centered relative to my parent window?
I played with the stuff you pushed into the wakefield project repo, it was clearly software rendering. And it is pretty good, reasonably fast, so it doesn't feel like it slow at all.
But there are some other things that are noticable, there was not gtk integration, or gnome integration, so the font were all black and white, because it wasn't picking up any of the desktop settings. The positioning thing was very obvious. The exceptions and messages continually being streamed to the console, but the overall UI was fine.
Regards to the windows positioning, clearly we have a modal and non-modal dialog, and it would be nice if non modal dialog could get the same positioning and treatment as modal dialogs.
As far as I know, Wayland does not provide any kind of positioning, as you already know. Definitely for modal windows, transient for kind of relationship.
It is not GTK that decides to put one window on top of the other, it is actually the Gnome compositor, and I think, for example, a tiling compositor may decide not to have modal windows, since it may not have a concept of it.
At this point there is no way to specify that one window should be on top of the another.
I understand that it is in general it is an unsolvable problem, as you said for a different kinds of compositors, for some of them the whole concept just does not make sense, but I think I saw some talk about maybe letting the window position to where it was last dissapered to at least give the user that consistency.
The xdg-session-management protocol is under discussion and it has not yet been merged. Basically, it allows a client to request that client windows be restored to the same positions as before.
We talked about the session manager in the past quite a while ago. I think we need to understand how we actually distinguish Java applications. It doesn't help with the first time, and even if this is absolute positioning, this window that I can recognize comes up with this position, but you really want it relative to your main window, and you window can may be moved around. It is not the something that happens only at startup, e.g. how to recognize a window shown before is the same window shown after, maybe the session manager takes care of all this in some clever way, but I am not sure about it.
First of all the problem of restoring a session and the problem of restoring a window position within the same session are slightly different.
For the latter, if you just want a window to appear where it was last time, and you haven't closed your session, I would be satisfied if a window manager would restore a window that has the same parent-child relationship with another window, and the same size as the last time this happened, but I'm dreaming.
It makes sense for some compositors, not sure if we do that. I think the Mutter already does some restoration things already, like when you unplug it and plug your external monitor back in, it also tries to do smart things.
At this point, the modal dialog is probably the best choice. The Gnome side has something centered in the middle, but it may not work across compositors.
I wanted to mention that the feature that centers modal dialogs in the center of its parent window is actually a notion, that can be disabled by user, so we can't rely on it, because some people just like me have disabled it. And it is not a standard, other compositors (e.g. KDE) may not be doing that.
Speaking of KDE, it worked by default, it tends to center a child window on top of the parent anyway. And it even centered our splash screen, which is essentially a borderless window. I understand that we should not rely on this all the time, but it is as good as it gets, if it works most of the time, or almost always is good enough for me.
Speaking of popups being different, there was a curious problem with popups that I ran into, while making the IDE work under Wayland. One of the most popular dialogs in the IDE is the search everywhere which comes up with double shift tap. It is actually implemented as a popup, and while I was implemented the ability to move it on the screen, with popups you cannot ask the compositor to do that for you, but you do have the ability to do it programatically. There is a curious problem with the interactive movement, when you move it together with your mouse, the window moves and the relative position(to the window that just moved) of the mouse also changes, it does not follow your mouse, it just jumps very erratically. You have to be very slow and careful to grab it.
Looks like there is no solution for that, other than to remake it with a proper dialog.
At the last meeting we raised a question about getting the Nikita's HiDPI fix into the mainline, is there an update on that? We have less than a month to get it into JDK 22.
If I understand correctly, just yesterday a problem was discovered with this fix, or rather an opportunity to improve it.
An XFCE user discovered a problem with window positioning, and it is quite persistent.
Online Zoom Meeting 9am PDT 12th Oct 2023
Attendees: Niels de Graef, Victor D'yakov, Phil Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev