On Sun, Jan 12, 2020 at 9:23 PM Ladislav Michl <[email protected]> wrote: > > Keep in mind that it will break any git-bisect plumbing people might run > on libs-back as you are intentionally creating point in history, where > things even do not compile.
I haven't thought about it that way before. This is worth considering, but I have not been strict about it in personal projects, and I'm not sure people have been strict about it here. I've treated it as follows: Git makes it a valid workflow to create chains that are not actually continuously functional; semantics and history may matter more. > Unfortunately I had to create GitHub account, but I'm happier with mail > and patches. I do not have a good workflow for mail+patches; if I would switch to mutt completely, it might be easier, but I don't use just mutt. Viewing diffs completely locally is also painful. Inline reviews with patches are much harder for me (as it becomes hard to view changes in full context). Github and its near-clones are not ideal for code review and collaboration, but for someone that hasn't dealt with mail patches, switching to them would be hard. However: I am still happy to accept them, I will just apply them to my local tree + push them somewhere (e.g. Github) as a reviewable chain. > Btw, in case you are not aware of https://wayland-book.com/ I recommend > reading it. It is certainly worth $10, but you can read it for free if > you are working on open-source project (condition met :)). Thank you for the reference to the book. I was happy to buy this to support Drew DeVault, despite this being for work on free software. Thank you also for the updates: I certainly wouldn't have known where to begin the API updates you've done in the fifth patch. It's good that I have the updated environment set up now, so I will be able to easily get back into debugging things. Primarily to more easily review what changed, I've opted to create a PR: https://github.com/gnustep/libs-back/pull/17 I've already hit what's likely a useful problem to spot: I'm getting the error here in _initWaylandContext in WaylandServer.m: if (!wlconfig->compositor || !wlconfig->wm_base) { [NSException raise: NSWindowServerCommunicationException format: @"Unable to get compositor"]; (In context: https://github.com/gnustep/libs-back/pull/17/commits/696ab6353488c203f4db68f1d62c9fd437bc0a6f#diff-659b64781af0473e6aa3f84a89e9ef8eR760 ) I understand that these are both supposed to be registered from the registry in the callback 'handle_global' (which maybe we should rename into 'registry_handle_global', as is in the book). I've modified this into two checks, and what's failing is wm_base. I've looked at SDL 2's source code and it looks like they support multiple shells, xdg_wm_base being only one of them (they call it just 'xdg'): 368 } else if (strcmp(interface, "xdg_wm_base") == 0) { 369 d->shell.xdg = wl_registry_bind(d->registry, id, &xdg_wm_base_interface, 1); 370 xdg_wm_base_add_listener(d->shell.xdg, &shell_listener_xdg, NULL); 371 } else if (strcmp(interface, "zxdg_shell_v6") == 0) { 372 d->shell.zxdg = wl_registry_bind(d->registry, id, &zxdg_shell_v6_interface, 1); 373 zxdg_shell_v6_add_listener(d->shell.zxdg, &shell_listener_zxdg, NULL); 374 } else if (strcmp(interface, "wl_shell") == 0) { 375 d->shell.wl = wl_registry_bind(d->registry, id, &wl_shell_interface, 1); 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? 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'll stop looking at this for today, as it's gotten late. Do you have any idea what might be going on?
