gnome-shell has  a nice integrated developer tool called “Looking glass”. To bring it up, simply enter “lg” into the command prompt:

Alt-F2 lg

This brings up a translucent overlay with an interactive JavaScript prompt. Among the nice things it offers are tab completion and an object picker.

Here is how it looks:

If you haven’t tried it yet,  you really should.

Over the years, many people have asked,

“Can I use Looking glass to debug my GTK+ application ?”.

So far, the answer has always been no. But now, the always awesome Alex Larsson has stepped up and made essentially the same functionality available for the GTK+ Inspector:

As you can see, it has an object picker, tab completion and a result history just like its ‘big brother’.  Alex made a little demo video for it.

To avoid a gjs dependency in GTK+ itself and the associated cyclic dependency issues, this is implemented as an extension in a loadable module.  The code currently lives on github, in Alex’ gjs-inspector repository.

Enjoy

GTK+ Inspector is a debugging tool that is built directly into GTK+ and is available in every GTK+ application by using of the shortcuts Ctrl-Shift-d or Ctrl-Shift-i.

Since I last wrote about it, a number of things have changed, so it is time to give an update on the state of GtkInspector as of GTK+ 3.15.2.

The UI has been revamped a bit to make best use of the limited space in the inspector window.  Some of our newer widgets, such as GtkStackSwitcher, GtkSidebar and GtkSearchEntry, were helpful here:

The object list has a new search implementation. It tries to deal better with search in a tree than the built-in search in GtkTreeView. Please try it and let me know what you think.

We’ve added a new feature: object statistics. This is made possible by corresponding new functionality in GLib. To enable it, run your application with

GOBJECT_DEBUG=instance-count

The inspector is now using a separate display connection.  This isolates it from many of the changes that you can make in it, such as CSS tweaks:

After 3.14, we have started to integrate OpenGL rendering into GTK+.  This is reflected in the inspector, which shows information about the OpenGL stack and offers some GL-related debug settings:

More recently, I’ve spent my coding time helping to make glade support all of the new GTK+ widgets and features.  We are not quite there yet, but you can already use client-side decorations, GtkHeaderBar, GtkSearchBar, GtkStack, GtkStackSwitcher and GtkSidebar with glade from git master.

I hope to add a few more new widgets to this list soon.  My personal goal for this effort is to use glade for all the ui files inside GTK+.

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

Update

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:

• What is this good for ?

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.

• Can I use this in my application ?

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.

• Does this also work with Wayland ?

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.

Overlay scrolling

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.

OpenGL support

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.

A Sidebar widget

Ikey Doherty contributed the GtkSidebar widget. It is a nice and clean widget to turn the pages of a GtkStack.

IPP Printing

The GTK+ print dialog can now handle IPP printers which don’t provide a PPD to describe their capabilities.

Pure CSS theming

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.

More to come

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.

Day 3

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.

Day 1

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.

Day 2

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:

• We (GNOME release team) should push for getting all users of webkit ported to webkit2 this cycle
• We should create a document that explains what application and service authors and distributors need to do when porting to kdbus

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

The Boston Summit is a 3-day hackfest for GNOME developers and contributors, that we traditionally hold over the Columbus day weekend.

In recent years, we’ve met in Montreal,  but for 2014,  we are back in Boston, at the MIT.

Details

When:    Saturday, October 11 — Monday, October 13
Where:  MIT building E51, Cambridge, MA

Topics

There’s plenty of topics we can discuss. Here are some I would be interested in working on:

• Application development (bundling, SDKs, sandboxing, kdbus, …)
• Wayland (porting leftovers, possibilities for the future, …)
• Privacy

If you are interested, please let us know you’re coming.

Hope to see many old and new faces there !

As part of the release preparation, I’ve done some smoketesting of GNOME 3.14 – looking good! As I usually do, I’ve taken some screenshots while testing things, to share some impressions. Now back to final release preparations.

At the release team BoF at this years Guadec, I said I would write a blog post about the whats and hows and ifs of release team work. I’m a little late with this, but here it is: a glimpse into the life of a GNOME release team member.

We are in the end phase of the development cycle, when the release team work is really kicking into high gear.

Blocker bugs

Since the .90 release, we’ve been tracking blocker bugs.  The way this works is that we are setting the GNOME Target field to the next release. During the cause of the development cycle, we’ve had 50 bugs that were marked with

GNOME Target=3.14

at some point . Today, we’re down to a single one, which will hopefully be gone before the weekend is over.

In order to draw our developers attention to these bugs, we’re sending out regular reports to desktop-devel-list (see them here, here and here). Andre has taken over this task this cycle.

We don’t have formal criteria for what bugs to mark as blockers, we are mostly going by the instinct and experience of bug zapping veterans like Andre Klapper. My own criteria for setting this flag mostly come down to these questions:

Is it a crash in a core component ?
Is it very visible or annoying ?
Will it affect many users ?

For finding bugs that should be blockers, I am regularly scanning all incoming bugs in bugzilla. On an average day this query finds between 100 and 200 bugs – with some practice, one can get through that list in 15 minutes.

We also get ‘nominations’ for blockers from maintainers and developers, which is very helpful.

Development Releases

The duty of ‘doing’ releases is distributed among all of the current, active release team members.

Our development schedule has a pretty well-established cadence of development  releases: We do a number of early development snapshots which are roughly a month apart (3.13.1, 3.13.2, 3.13.3 and 3.13.4 this cycle), followed by the beta releases which are 2 weeks apart (3.13.90, 3.13.91, 3.13.92, this cycle).

The end product of each development release is a set of jhbuild modulesets and a forest of symlinks to the tarballs for individual modules that are included in the release.

Most of the mechanics of creating the modulesets by rewriting our regular modulesets (which point at git repositories, not tarballs), and creating those symlinks on the server are handled by scripts that have been passed down through the generations.

The time-consuming aspect of creating a release is that it usually takes several attempts to create candidate modulesets, hunt down missing releases (or doing them ourselves – which is sadly necessary for a number of ‘weakly maintained’ modules), and do a full jhbuild using the final modulesets. As a consequence, while our official release day is always Monday, the release typically happens on Wednesday or Thursday of the same week.

Planning

Towards the end of a development cycle, the release team also starts to plan for the next cycle.

This includes creating the schedule, taking a look at annoying bugs that we should tackle in the next cycle, figuring out if there are project-wide goals that we should push, and collecting input on new modules and features that people want to work on for the next release.

Since we are at this point right now, let me end with this request:

Please let us know what features are on your modules roadmap for the next cycle!