Who wrote GTK+ 3.22

Now that GTK+ 3.22.0 and GLib 2.50.0 have been released, it’s time to look back at this development cycle and see the contributions from people and companies that made these releases possible.

Activity

During the 3.22 development cycle, GLib saw a total of 14119 lines added, 2031 removed, for a net gain of 12088 lines:

glib-changes-3-22GTK+, instead, saw a total of 46581 lines added, 19163 removed, for a net gain of 27418 lines:

gtk-changes-3-22

The statistics do not include translations.

Contributors
GLib

GLib saw contributions from 60 individuals:

glib-contributors-3-22

The trend for contributors in GLib in increasing, even if the size of changes has decreasing.

Developers with the most changesets
Matthias Clasen 60 24.7%
Philip Withnall 44 18.1%
Chun-wei Fan 18 7.4%
Mario Sanchez Prada 10 4.1%
Allison Lortie 7 2.9%
Ruslan Izhbulatov 7 2.9%
Emmanuele Bassi 6 2.5%
Krzesimir Nowak 6 2.5%
Jonh Wendell 5 2.1%
Cosimo Cecchi 5 2.1%
Simon McVittie 4 1.6%
Ondrej Holy 4 1.6%
Christoph Reiter 4 1.6%
Rico Tzschichholz 3 1.2%
Dan Winship 3 1.2%
Aurélien Zanelli 3 1.2%
Kjell Ahlstedt 2 0.8%
Piotr Drąg 2 0.8%
Colin Walters 2 0.8%
Emilio Pozuelo Monfort 2 0.8%
Developers with the most changed lines
Matthias Clasen 7797 53.6%
Philip Withnall 2736 18.8%
Cosimo Cecchi 767 5.3%
Chun-wei Fan 674 4.6%
Mario Sanchez Prada 418 2.9%
Allison Lortie 365 2.5%
Christoph Reiter 319 2.2%
Krzesimir Nowak 220 1.5%
Jonh Wendell 178 1.2%
Ruslan Izhbulatov 163 1.1%
Marc-Antoine Perennou 142 1.0%
Emmanuele Bassi 104 0.7%
Tim-Philipp Müller 81 0.6%
Benjamin Otte 79 0.5%
Ondrej Holy 48 0.3%
Giovanni Campagna 43 0.3%
Jeremy Whiting 34 0.2%
Debarshi Ray 33 0.2%
Stephan Bergmann 32 0.2%
Christian Persch 30 0.2%

Matthias Clasen and Philip Withnall have been the biggest contributors, this cycle. Matthias worked on the portals implementation for allowing sandboxed applications to access system services; Philip worked on the new structured logging API.

GTK+

GTK+ saw contributions from 75 developers:

gtk-contributors-3-22

The number of contributors is trending downwards, and given that the amount of changes has also reduced, it’s likely a reflection on the overall stabilization process towards the 3.22 long term release.

Developers with the most changesets
Matthias Clasen 369 37.3%
Lapo Calamandrei 73 7.4%
Carlos Garnacho 69 7.0%
Timm Bäder 67 6.8%
Emmanuele Bassi 60 6.1%
Ruslan Izhbulatov 30 3.0%
Jonas Ådahl 28 2.8%
Benjamin Otte 25 2.5%
Olivier Fourdan 21 2.1%
Matt Watson 21 2.1%
Sébastien Wilmet 18 1.8%
Chun-wei Fan 13 1.3%
Andreas Pokorny 12 1.2%
Georges Basile Stavracas Neto 12 1.2%
Christian Hergert 12 1.2%
Piotr Drąg 11 1.1%
Tristan Van Berkom 11 1.1%
Ray Strode 10 1.0%
Stephen Chandler Paul 9 0.9%
William Hua 8 0.8%
Developers with the most changed lines
Matthias Clasen 14378 28.2%
William Hua 6212 12.2%
Ruslan Izhbulatov 5222 10.2%
Lapo Calamandrei 4383 8.6%
Carlos Garnacho 3510 6.9%
Emmanuele Bassi 1947 3.8%
Matt Watson 1811 3.6%
Georges Basile Stavracas Neto 1805 3.5%
Jonas Ådahl 1647 3.2%
Chun-wei Fan 1195 2.3%
Stephen Chandler Paul 1099 2.2%
Timm Bäder 1018 2.0%
Sébastien Wilmet 865 1.7%
Benjamin Otte 793 1.6%
Javier Jardón 655 1.3%
Alexander Larsson 486 1.0%
Andreas Pokorny 358 0.7%
Tristan Van Berkom 333 0.7%
Jakub Steiner 317 0.6%
Mohammed Sadiq 298 0.6%

Just like he did in GLib, Matthias worked on implementing support for portals inside GTK+, especially the ones that require user interaction like file selection and printing; Carlos Garnacho worked on the graphic tablets support in Wayland; Jonas Ådahl and Olivier Fourdan worked on the windowing system issues of the Wayland backend; William Hua worked on improving the Mir backend; Ruslan Izhbulatov and Chun-wei Fan worked on the Windows backend, especially with regards to keyboard input; Emmanuele worked on adding GLES support to the GdkGLContext API; Timm Bäder worked on GtkPopover; Matt Watson worked on GtkStack and the internal animation handling.

Affiliations

As usual, much of these changes would not have been possible without the contribution of various companies.

For GLib:

Top changeset contributors by employer
Red Hat 84 34.6%
(Unknown) 78 32.1%
Collabora 43 17.7%
Endless 22 9.1%
Canonical 12 4.9%
Centricular 2 0.8%
Intel 2 0.8%
Employers with the most hackers
(Unknown) 33 52.4%
Red Hat 14 22.2%
Collabora 4 6.3%
Endless 4 6.3%
Canonical 4 6.3%
Centricular 2 3.2%
Intel 2 3.2%

For GTK+:

Top changeset contributors by employer
Red Hat 548 55.4%
(Unknown) 333 33.7%
Endless 97 9.8%
Collabora 6 0.6%
Canonical 4 0.4%
Centricular 1 0.1%
Employers with the most hackers
(Unknown) 49 63.6%
Red Hat 16 20.8%
Endless 6 7.8%
Collabora 3 3.9%
Canonical 2 2.6%
Centricular 1 1.3%

This Week in GTK+ – 18

In this last week, the master branch of GTK+ has seen 33 commits, with 9362 lines added and 8025 lines removed.

Planning and status
  • Matthias released GTK+ 3.21.6, the last snapshot before the 3.22.0 release of September 21st.
  • The GTK+ road map is available on the wiki.
Notable changes
  • This week we had mostly translations for property descriptions and user-visibile messages, in preparation for the 3.22 release.
  • Ruslan fixed the GdkEventKey.is_modifier() structure field on Windows to report Ctrl, Alt, and Shift keys as modifiers.
  • Jonas Ådahl landed last minute fixes for combo boxes and other popups under Wayland.

Bugs fixed

  • 771117 gtk3 3.21.5 broke displaying drop-down lists, need to scroll to see contents
  • 771349 gdk_screen_get_monitor_scale_factor on X11 always returns 1 with GTK 3.21+
  • 771463 variable may be used uninitialized in gtk_widget_render
  • 602773 GdkEventKey.is_modifier is 0 for Shift, Ctrl, Alt keys
Getting involved

Interested in working on GTK+? Look at the list of bugs for newcomers and join the IRC channel #gtk+ on irc.gnome.org.

This Week in GTK+ – 17

In this last week, the master branch of GTK+ has seen 41 commits, with 19871 lines added and 16800 lines removed.

Planning and status
Notable changes
  • Matthias added a --version command line switch to small binaries shipped with GTK+, like gtk-launch and gtk3-demo; this allows checking the version of GTK+ on the system without resorting to distribution packages or development files.
  • The X11 backend of GDK now properly detects XRandR 1.5 support in VirtualBox.

Bugs fixed

  • 767391 cross-fade() not cross-fading
  • 771033 GtkStatusIcon cannot show activate menu in VirtualBox since 3.21.2
  • 764979 Connect to server is unusable after cancelling a password dialog
  • 770278 modernize example applications
  • 770508 [REGRESSION][BISECTED] Recent change in GtkTreeView::grab_focus_and_unset_draw_keyfocus() breaks shortcut assignment
  • 770906 Wayland: Unmapping a toplevel from a menu/popup can lead to a protocol error
Getting involved

Interested in working on GTK+? Look at the list of bugs for newcomers and join the IRC channel #gtk+ on irc.gnome.org.

This Week in GTK+ – 16

In this last week, the master branch of GTK+ has seen 32 commits, with 5125 lines added and 4393 lines removed.

Planning and status
  • Matthias released GTK+ 3.21.5, likely the last developers snapshot before the 3.22.0 release.
  • The GTK+ road map is available on the wiki.
Notable changes
  • GTK+ requires version 1.7 of the Wayland protocols definitions, in order to use v6 of the xdg_shell protocol.
  • GtkScrolledWindow can now optionally propagate the preferred natural size of its child to the parent.

Bugs fixed

  • 770550 gtkplacessidebar: fix signal marshal
  • 770458 GtkAboutDialog issue with long credit lists and GtkScrolledWindow
  • 770307 Crash when closing a glade project
  • 770624 [PATCHes] Fix typos.
  • 770745 wayland: Warn when an application tries to map popup incorrectly
  • 769498 Scrollbars are broken
  • 770703 Fix crash when using page-down on GtkListBox
  • 770614 GtkScale in HighContrast theme with value = 0: WARNING: allocates negative content width/height to node highlight
  • 770849 GtkLabel with padding brokenness
  • 766569 Better size requisition for GTK_SCROLL_NATURAL children
Getting involved

Interested in working on GTK+? Look at the list of bugs for newcomers and join the IRC channel #gtk+ on irc.gnome.org.

Versioning and long term stability promise in GTK+

The plans set out in this post supersede those that were publicised after the Toronto GTK+ hackfest in June 2016.

This month, the GTK+ team will publish the first in a series of long-term stable releases. This will make GTK+ more predictable and reliable, while not inhibiting future GTK+ improvements.

These plans are a result of discussions held with a variety of stakeholders since initial plans were made at the GTK+ hackfest in Toronto last June.

Background

GTK+ has followed a fairly straightforward versioning scheme since the 2.0 release in 2002:

  • major versions designate the general API version
  • minor versions designate development cycles (if odd) and stable cycles (if even)
  • micro versions designate bug fix updates

Any API introduced in GTK+ is guaranteed to exist until the next major version; API introduced during a development cycle is guaranteed to remain once the stable cycle begins. Stable cycles do not provide new features or new API.

This scheme served us well, but its problems have become increasingly clear during the 3.x series, especially when coupled with 6 month, time-based development cycles. During the 2.x cycle new features in GNOME applications were forced to appear in additional libraries because the toolkit was too complex or moving too slowly. Since 3.0, the development pace of GTK+ has been picking up. GTK+ has been placed front and center, with new widgets and new functionality being introduced every six months. In order to implement these new widgets and functionality, though, some of the toolkit’s internals have been in a state of flux.

From a GNOME perspective, GTK+ has been a reasonably stable, albeit moving target, because GNOME developers and GTK+ developers can share feedback and proposals and quickly keep up with internal changes. From the perspective of the community, on the other hand, following GTK+ development has been more painful. Application developers outside of the GNOME project have had a hard time finding out about what changes in the toolkit will impact their codebases. The GTK+ team has attempted to improve its communication channels, but blogging about changes during development cycles hasn’t been enough for many in the wider community of GTK+ users.

Long-term stable GTK+ releases

GTK+ has three primary stakeholders: application developers who want feature and API stable releases; desktop developers who want access to development versions of GTK+ in order to introduce new functionality at a rapid pace (this includes most of the GNOME project); and the GTK+ team itself, which needs the ability to iterate on the internals of the library during longer development cycles.

The introduction of long-term stable GTK+ releases is designed to ensure that GTK+ strikes a good balance between each of these audiences. In particular, application developers will have access to a stable platform which nonetheless provides access to new GTK+ features that have been developed during the 3.x series, such as CSS styling, touchscreen support, HiDPI displays support, Wayland support, new widgets, the GTK+ inspector, and more.

GTK+ will continue to publish major, minor and micro releases. New major versions will be released once new features have stabilised, which is expected to be roughly every 2-3 years. When bumping to a new major version deprecated API will be removed. After that, this API series will be considered stable. New minor releases may introduce new widgets, or update the implementation of windowing system protocols in the GDK backends, but no additional features or theme changes will be allowed. Whereas previously minor releases were published every six months, now they will be produced as and when necessary. We’ll also keep doing micro releases for bug fixes and security issues, for at least three years. Maintenance after this point may continue, depending on the amount of volunteer resources available. Distributors of operating systems with long term support release cycles that extend past three years may want to contact the GTK team to establish a policy for backports.

Updates within long-term stable series will be ABI stable. Alongside these stable series, GTK+ development will continue in semi-stable development series. These development releases will contain some API changes between minor versions, although changes will be limited wherever possible. This is the path that we expect GNOME applications to take, but other application developers may choose this option if they want access to the latest features, at the cost of some potential porting work for each minor release.

While the GTK+ team reserves the right to change API during development series, this does not mean that the whole GTK+ API will constantly break each release; only specific, and hopefully rarely used parts of the API may change, and if the changes are too extensive they will very likely be delayed to the next major development cycle. We’ll ensure that these changes are well-communicated in advance.

The new versioning scheme

The new GTK+ versioning scheme is a modification of the “semantic versioning” scheme that we have followed until now. Once a new major stable release has been published, the development cycle starts and we will:

  • update the pkg-config file to a new major version, to allow GNOME developers to target the new API during development
  • keep the existing major version at the same number
  • update the minor version to 90 to indicate a development release

For instance, after the 3.22.0 release and at the start of the new development cycle, the pkg-config file will be called gtk+-4.0 and the version in the configure.ac file will be set to 3.90.

Every six months a new even development version will be released, such as x.90, x.92, x.94, until the GTK+ team is confident that the new API and feature set are stable. Each of these minor versions will bump the soname of the shared library, to ensure that automated tools can pick up the eventual changes and notify distributors and maintainers. Once we reach the point where the API and feature set is stable enough for the wider community to use, we will release a new major version (x + 1).0 and declare the API stable.

Once this point-zero release has been made, a new stable branch will be created, and the master branch will be bumped to the next point-ninety release and begin the new development cycle. The point-ninenty releases will be parallel installable with the previous stable releases.

gtk-versioning-scheme

3.22 will be the last minor release of the 3.x series, with the new versioning scheme coming into effect with 3.90. The 3.22 release is irregular in the scheme, in that it is a long-term stable version but won’t receive further minor releases and doesn’t have a .0 version number. This is a necessary transition step.

What’s next

More details about these plans, including specifics for library developers and distribution packagers, will follow in subsequent blog posts. The GTK+ development blog will also continue to provide updates about technical changes in GTK+ itself, in order to provide information about which changes will arrive in each upcoming major release.

We’re excited about these plans and are hopeful that they will usher in a new era for GTK+, in which application authors can be more confident in our platform, while still allowing the rapid pace of development that we have seen during the 3.x series.

The plans set out in this post supersede those that were publicised after the Toronto GTK+ hackfest in June 2016.