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 12th Oct 2023
Attendees: Niels de Graef, Victor D'yakov, Phil Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev
The fix for taking screenshots on a displays with different scales is integrated.
It looks like we will support X11 compatibility mode in the next JDK release(at least for Ubuntu 22.04 for now). Probably we'll also include the latest Oracle Linux and RHEL.
Let's try to test the latest Fedora as well, I know it is not on Oracle supported Linux list.
I recall that a fix for HiDPI support in X11 compatibility mode was posted to the Wakefield mailing list for the Wakefield sandbox, I think it is a good time to integrate it to mainline(JDK 22).
I think it was dependent on some other minor thing that I did, but I also don't remember the fate of it. I'll check on that, if the dependency is in the mainline, I'll ping the guy responsible for the fix.
Actual rendering with Vulkan started to happen, there is some progress in this area, but not very visual.
I did some minor fixes here and there in the Wayland prototype, I implemented the clipboard support, I started working on DnD, but it turned out that is a lot larger that clipboard support.
We are trying to wrap things up to come up with a more or less working solution to show the JetBrains IDE, actually at this point, the goal is almost on the side IDE,
they do some funny stuff with popups, some of them show up in weird places. It is practically the main major thing that prevents IDE from being usable from pure Wayland toolkit.
Tried to run this thing on KDE, but faced some KDE issues, like XServer is crashing every several minutes, unable to logout without killing something, etc.
We also have some difficulties to setup out testing virtual systems in the cloud to start with Wayland session, no matter of the config, investigation is ongoing.
The amount of tests is not significant, I managed to choose 400 hand picked tests, that still run in pure Wayland session, we have to use som jtreg 7.3 to pass all required env variable.
Those 400 are picked that can be used unmodified, so don't use Robot, don't rely on positioning of a window exactly, etc, but they still make sense.
I have a question related to splashscreen, how do we implement the decision which toolkit to use, especially when the splashscreen to be shown?
We still have the positioning issue for Wayland windows(we can't contol their position), we can use the X11 splashscreen since it doesn't have one(for now). Even if the toolkit will be Wayland later.
The positioning problem is sort of solvable with a large transparent window to the size of the screen, and then draw you splashscreen inside of it, but the problem of having an X11 splashscreen
and then proceeding later with the Wayland toolkit that you have to have the ability to draw over the splashscreen once toolkit get loaded.
You have to have a handle of a window that you showed during the startup, and then that handle has to be reused somehow when you have your AWT,
when you can paint and everything else, so it has to stay within one toolkit.
Can we just tear down a splashscreen window and then immediately start a new one?
It is not technically possible, the shared code, the infrastructure that works on all the other platforms is set up such that at a startup you fire up a window
with the ability to save its opaque handle to the window for the code that comes later and be able to draw on that window, other than a static image that we took from a file(jpg, png gif).
If we tear it down, at least there'll be some kind of flicker.
For now, if you want just to test this out, if this in production, I would stick for X11 for a while, and I only switch to the Wayland implementation where there is a high level of confidence.
But you obviously want to test out the Wayland implementation, so I would just use an environment variable.
That is the only thing that touches shared code. Do you have some recomendations what's not to do in shared code?
Because this platform is so specific, so it has two toolkits.
For now just do what you have to do in the shared code, and we refine it later.
Just wondering in regards to CI problem that you have, so one thing you could do is just run mutter or even gnome shell as headless.
That you can use to immediatelly run it as Wayland compositor.
gnome-shell --headless --wayland --virtual-monitor 1920x1080
Online Online Zoom Meeting 9am PDT 17th Aug 2023