Some updates, especially. for those who didn't follow https://github.com/gnustep/libs-back/pull/17.
Fred and I have chosen to merge sooner rather than later. Despite the rendering being ultra buggy (screenshots posted on the pull request above -- floating wayland surfaces seem to be created even for backing NSView surfaces, and are drawn on the screen), we'll likely merge the backend in the current state so it can be iterated upon in the main branch. Besides the obvious, immediately visible bugs, there are a lot of little things that we can and should change in the implementation. For one, I think C structs might be overused, and I'd like to hand off event handling to ObjC objects earlier even if the handlers have to be a C class. But, looking at the x11 subclass of GSDisplayServer, things are pretty messy there, too, so I don't feel that bad about merging messy code -- I feel bad only about those bugs that I didn't get around to looking at. I am somewhat torn on whether this should be a separate displayserver backend, however; in the typical GNUstep approach, it should, but with GTK the actual "GDK" backend gets autodetected based on presence of a Wayland environment, and can be overridden with an environment variable. Should we perhaps build both X11 and Wayland displayserver into the same lib, and switch between them at runtime, to match the behavior of other toolkit libs? On Mon, Jan 27, 2020 at 9:49 PM Ladislav Michl <[email protected]> wrote: > > > I'm running Weston from Debian buster (current stable). It seems to be > > Weston 5.0.0. And this Phoronix article: > > https://www.phoronix.com/scan.php?page=news_item&px=Weston-6.0-XDG-Shell-Stable > > says that only Weston 6.0 support 'xdg-shell stable'. I suspect this > > is exactly what we need, as xdg_wm_base functions seem to be defined > > in /usr/share/wayland-protocols/stable/xdg-shell/xdg-shell.xml on my > > machine. > > > > Ladislav, do you think it's worth supporting other shell APIs? Are you > > interested in writing this? > > Eh, I've never seen any Wayland nor libs-back code before touching this, > so I'm certainly not qualified enough to anwer that question. > > However, my messy work in progress contains something like this > #ifdef XDG_SHELL > ... > #else > static void > wl_shell_surface_on_ping(void *data, struct wl_shell_surface *shell_surface, > uint32_t serial) > but I've never tested #else branch and later found this blog entry: > https://drewdevault.com/2018/07/29/Wayland-shells.html > with those notes interesting here: > "xdg-shell is currently the only shell whose protocol is considered stable, > and it is the shell which describes application windows." > and > "wl_shell, the now-deprecated original desktop shell of Wayland" I've opted not to deal with this in the beginning, and simply require the stable XDG Shell protocol. I expect this is not going to be a problem for a new implementation that we're launching in 2020. > > > However, that's not the only problem I've run into. The second one is > > more worrying. Even after biting the bullet and installing Weston 6 > > from Debian testing, I'm getting 'xdg_surface@12: error 3: xdg_surface > > has never been configured' from the client app (and from weston, > > '[21:59:20.865] libwayland: error in client communication (pid > > 99330)'. Rebuilding the protocol source/headers doesn't help. I've > > checked and made sure that all Wayland and Weston-related libraries > > that I could find are up to date. Apps I tested are Calculator.app > > from GUI examples and SystemPreferences.app. > > > > This sounds like the surface has in general not been 'configured': > > https://patches.videolan.org/patch/20875/ I've worked around this. Some details in the PR. > > I solved it similar way as above patch does. I'm using Debian unstable > running Gnome session and things just worked somehow here. But I was > unable to debug using xdg_popup windows for menus, etc. It always > crashed Gnome session. So I cross-compiled everything to embedded > targed and used Wayland-1.17.0 and Weston-7.0.0 and run into the > same issue as you. It sounds like things have at some point worked fine for you. But everything is ultra messy for me ever since I got the implementation not to crash. If you have a clear idea about what my changes did to break the implementation, i.e. why there are floating cairo surfaces all over the place, let me know. I have my suspicions (WaylandCairoSurface likely shouldn't instantiate a wayland surface for every cairo surface, but only do so on demand?) but I didn't get to dig into this.
