After a bit more debugging, and with some help from Jasper, here is the inspector debugging an X11 application while displaying under Wayland:
It also turns out that the GTK_INSPECTOR_DISPLAY environment variable is sufficient to make this work. I started this demo with
GTK_DEBUG=interactive GDK_BACKEND=x11,wayland \ GTK_INSPECTOR_DISPLAY=wayland-0 ./gtk3-demo
The reverse (application displaying under Wayland, inspector on X) also works:
I’ve been working on making GtkInspector use a different display connection. This helps isolating it from some of the changes you can trigger from inside the inspector UI. Then I thought, why not use a different backend ?!
We did enough work on GDK backend separation that it could almost work. But since we didn’t add API to actually connect to specific backends (users and applications get some control with GDK_BACKEND and gdk_set_allowed_backends()), nobody has ever used multiple backends in the same process. And things that don’t get used don’t work. So some fixes were necessary.
But now I have gtk3-demo running under X while the inspector is using the Broadway backend and shows up in the web browser:
To my knowledge this is the first time a GTK+ application is using multiple GDK backends at the same time.
Anticipating some questions:
Not that much, really. I consider it mostly a curiosity. It does prove that the GDK backend separation is (almost) working.
For most cases where this could be used with the inspector, it is probably preferable to move the inspector out of process and communicate via D-Bus. There are some people who are interested in this, so it may happen.
No. I haven’t committed that hack that makes the inspector use a different backend . If we wanted to support this, we would need to add a real API to connect to a specific backend.
What I did commit though is the code that makes the inspector always use a separate display connection (with the same backend), so you get the better isolation that can be seen in the video.
No. I first tried to make it work with Wayland+X, but the Wayland backend is more complicated than Broadway. I’m still getting crashes fairly soon. Broadway pretty much just worked, after a round of fixes.
A number of new features have landed in GTK+ recently. These are now available in the 3.15.0 release. Here is a quick look at some of them.
We’ve had long-standing feature requests to turn scrollbars into overlayed indicators, for touch systems. An implementation of this idea has been merged now. We show traditional scrollbars when a mouse is detected, otherwise we fade in narrow, translucent indicators. The indicators are rendered on top of the content and don’t take up extra space. When you move the pointer over the indicator, it turns into a full-width scrollbar that can be used as such.
Other new scrolling-related features are support for synchronized scrolling of multiple scrolled windows with a shared scrollbar (like in the meld side-by-side view), and an ::edge-overshot signal that is generated when the user ‘overshoots’ the scrolling at either end.
This is another very old request – GtkGLExt and GtkGLArea have been around for more than a decade. In 3.16, GTK+ will come with a GtkGLArea widget.
Alex’ commit message explains all the details, but the high-level summary is that we now render with OpenGL when we have to, and we can fully control the stacking of pieces that are rendered with OpenGL or with cairo: You can have a translucent popup over a 3D scene, or mix buttons into your 3D views.
While it is nice to have a GLArea widget, the real purpose is to prepare GDK for Emmanuele’s scene graph work, GSK.
Ikey Doherty contributed the GtkSidebar widget. It is a nice and clean widget to turn the pages of a GtkStack.
The GTK+ print dialog can now handle IPP printers which don’t provide a PPD to describe their capabilities.
For the last few years, we’ve implemented more and more CSS functionality in the GTK+ style code. In 3.14, we were able to turn Adwaita into a pure CSS theme. Since CSS has clear semantics that don’t include ‘call out to arbitrary drawing code’, we are not loading and using theme engines anymore.
We’ve landed this change early in 3.15 to give theme authors enough time to convert their themes to CSS.
With these features, we are about halfway through our plans for 3.16. You can look at the GTK+ roadmap to see what else we hope to achieve in the next few months.
The last day of the Summit was a hacking-focused day.
In one corner, Rob Taylor was bringing up Linux and GNOME on an Arm tablet. Next to him, Javier Jardon was working on a local gnome-continuous instance . Michael Cantanzaro and Robert Schroll were working on D-Bus communication to let geary use Webkit2. Christan Hergert was adding editor preferences to gnome-builder and reviewed design ideas with Ryan Lerch. I spent most of the day teaching glade about new widgets in GTK+. I also merged OpenGL support for GTK+.
Overall, a quite productive day.
Thanks again to the sponsors
and to Walter Bender and the MIT for hosting us.
The Boston summit is well underway, time for some update on what is happening.
Around 20 people got together Saturday morning and, after bagels and coffee got together in a room and collected topics that everybody was interested in working on. With Christian in attendance, gnome-builder was high on the list, but OSTree and gnome-continuous also showed up several times on the list.
Our first session was discussing issues of application writers with GTK+. Examples that were mentioned are the headerbar child order changing between 3.10 and 3.12, and icon sizes changing for some icons between 3.12 and 3.14 . We haven’t come to any great conclusions as to what we can do here, other than being careful about changes. GTK+ has a README file that gets updated with release notes for each major release, but it is not very visible. I will make an effort to draw attention to such potentially problematic changes earlier in the cycle.
Another kind of problem that was pointed out is that the old way of doing action-based menus with GtkAction and GtkUIBuilder has been deprecated, but the ‘new way’ with GAction, GMenuModel and GtkApplication has not really been fully developed yet; at least, there is not great documentation for migrating from the old to the new, or for just starting from scratch with the new way. The HowDoI‘s for this are a start, but not sufficient.
After the morning session, Richard Stallman came by and spent an hour with us, discussing the history of free software, current challenges, and how GNOME fits into this larger picture from his perspective.
In the afternoon, we had a long session discussion ‘future apps’, which is hard to summarize. It revolved around runtimes, sdks, bundling, pros and cons of btrfs vs ostree, portals, how to get apps ported to it, what to do about qt apps. This thread covers a lot of the same ground.
I managed to land GType statistics support in GObject and GtkInspector.
Over breakfast, we talked about the best way to communicate with a webkit webview process, which somehow led us to kdbus. Takeaways from this discussion:
After breakfast, we started out with a live demo of gnome-builder, which looks really promising. Christian is reusing a lot of existing things, from gtksourceview over devhelp to gitg and glade. But having a polished, unified application bringing it all together makes a real difference!
As this session was winding down, I started testing a GNOME 3.14.0 Wayland session with the goal of recording as many of the smaller (and larger) issues as possible in bugs. The result so far can be found here. While I reported a long list of Wayland issues today, all is not bad. It was no problem at all to write this blog post in a Wayland session!
Thanks to Red Hat and Codethink, who are sponsoring this event
