A talk in 9 images

My talk at GUADEC this year was about GTK+ dialogs. The first half of the talk consisted of a comparison of dialogs in GTK+ 2, in GTK+ 3 under gnome-shell and in GTK+ 3 under xfwm4 (as an example of an environment that does not favor client-side decorations).

The main take-away here should be that in 3.14, all GTK+ dialogs will again have traditional decorations if that is what works best in the environment it is used in.

About DialogsPreference DialogsFile ChoosersMessage DialogsError DialogsPrint DialogsFont DialogsColor DialogsAction DialogsThe second part of my talk was discussing best practices for dealing with various issues that can come up with custom GTK+ dialogs; I’ve summarized the main points in this HowDoI page.

Continuous testing and Wayland

The GNOME-Continuous  continuous integration and delivery system has been helping us to keep the quality of the GNOME code base up for a while now.

It is doing a number of things:

  • Builds changed modules
  • Creates vm images that can be downloaded for local testing
  • Smoke-tests the installed image  by verifying that it boots up to the login screen
  • Runs  more than 400 tests against the installed image
  • Launches all the applications that are part of the moduleset and takes screenshots of them

All of this happens after every commit, or at least very close to that, and the results are available at the build.gnome.org website.

You can learn more about GNOME-Continuous here.

As a member of the the GNOME release team I am really thankful for this service, it has made our job a lot easier – at release time everything just builds and works most of the time nowadays.

Earlier this year, we’ve made the smoke-testing aspect of gnome-continuous more useful by verifying not just GNOME, but also GNOME Classic and GNOME on Wayland.

Today, we’ve had a minor breakthrough: for the first time, the GNOME/Wayland smoke test succeeded all the way to taking a screenshot of the session.

GNOME/Wayland(of course, GNOME on Wayland looks just like GNOME under X11, so the screenshot is not very exciting by itself).

To get this far, we had to switch to the egl-drm branch of mesa, which adds support for running KMS+DRM GL applications with QXL.

GTK+ at GUADEC 2014

GUADEC is almost here. GTK+ will be presented with 3 talks:

  • GTK+, dialogs, the HIG and you  (by me)
  • GTK+ and CSS (by Benjamin)
  • The GTK+ scene graph toolkit (by Emmanuele)

All of these will be on Monday, the 28th. We will also have a GTK+ team meeting on the 31st.

I’ve made a small collage to summarize my talk:

Dialogs See you all there !

Another GtkInspector update

I’ve last written about GtkInspector in early June. Since then, a few things have fallen into place, so it is time for another status update.

Show all the things

An early focus of my work on the inspector was to make as much information visible as possible (objects, styles, settings,…).

MenusThis has continued; the most recent addition in the object tree are submenus and combobox popups, which are now shown below the widgets they are attached to.

StyleFor widgets, we now have a Style Properties tab, which shows the values of known style properties, and importantly, where they originate in the theme css. This tab is still a bit preliminary,  but it is a start towards answering the question: why does GTK+ not pick up this selector in my css ?

Property BindingSettings Binding

The property editor popover in the Properties tab is now showing information about GObject and GSettings property bindings, with an easy way to jump to the other object.

The environment section in the General tab includes GSETTINGS_SCHEMA_DIR when set.

Test all the things

Next to making things visible, the inspector is supposed to make it easy to test an application in various situations, such as different themes or right-to-left locales.

GeneralAn recent addition in this regard is a switch in the General tab to turn on touchscreen simulation. This used to be available only via the GTK_TEST_TOUCHSCREEN environment variable.

Hi-dpiYou can also turn on hi-dpi scaling in the General tab to test how your app behaves in this scenario, and look out for blurry icons and the like. Careful, this will make your windows giant.

Better picking

I found that I often use the widget picker right after opening the inspector window, so I figured that I should try to combine these two actions. As a result, Ctrl-Shift-I will now open the inspector and select the widget that was under the pointer before. Ctrl-Shift-D still toggles the inspector on and off.

Another small improvement to picking is that the Escape key can now be used to cancel a picking operation.

Less confusion

As I’ve mentioned above, some of the things that the inspector lets you change at runtime can also be set from environment variables (e.g. GTK_THEME). And when they are set, the environment variables often override any runtime changes.

Disabled controlGtkInspector now reflects this by disabling the corresponding controls when they won’t take effect.

Help welcome

I’ll continue to improve the inspector, but there’s more good ideas for possible features than one person can handle. If you want to help out, feel free to come by on irc, or just put your contribution in bugzilla, where the inspector has its own component now.