Tag: Release

The GTK 3.99.2 release continues the topics from 3.99.1: api cleanup, new and polished demos, better documentation. You can see the details here.

One small note on the topic of documentation is that we are relying on some unreleased gtk-doc features. Therefore, we now include gtk-doc as a subproject in the gtk release tarball. If you are a distributor, don’t be surprised that building GTK installs gtk-doc tools now.

The big news in this snapshot is our work on exposing the power of the new GL-based rendering stack a bit more.

Warmup: Shadertoy

gtk4-demo includes a Shadertoy demo now.

The demo using a GtkGLArea widget to run GLSL snipplets that are compatible with the ones found on shadertoy.com. Many of the examples found there will work, if you paste them into the editor of this demo.

This is fun, but somewhat limited. The GLSL is confined to its ‘sandbox’, the GtkGLArea widget, which is using GL api to compile and use the shaders.

Shaders as first-class objects

This is not our first attempt to make a shadertoy lookalike. When we first looked at it, we thought that we would make a shader abstraction that applications could use. We put it to the side when it turned out that making it work across different renderers and backends would require us to write our own shader compiler—too much work.

But after our shadertoy success, we revisited the idea of shaders as first-class objects, with more modest goals: We use GLSL, and don’t attempt to make the shaders work with anything but the OpenGL renderer.

In 3.99.2, we now have:

• GskGLShader – a wrapper object around a GLSL fragment shader
• GskGLShaderNode – a render node that lets us embed a GskGLShader in the scene graph
• gtk_snapshot_push_gl_shader convenience api to lets widgets easily add shader nodes to their rendering

With these pieces in place, we made a demo that shows various uses of shaders. It is maybe a bit overloaded, and some of the effects are a bit over-the-top, but it gets the point across: you can use shaders in your widgets.

 

What we haven’t done yet is adding widgets that have shader support built-in. The demo showcases a few likely candidates:

A shader paintable. As you may recall, GdkPaintable is a very flexible interface for anything that can ‘paint’. Shaders certainly qualify. The GskShaderPaintable in gtk-demo uses a shader without input textures to just produce pixels, and we add it to a GtkPicture widget to make it appear in the widget tree.

A shader bin. This is a very simple container that can use shaders to draw effects on top of a child widget. It works with shaders that take a single input texture (for the child widget).

A shader stack. This is a stack-like container that shows one of many child widgets, and uses a shader for the transition whenever the visible child changes. It works with shaders that expect two input textures (for the old and new active child).

Thankfully, making custom widgets is a lot easier in GTK 4 than it used to be, so the render node API should be enough to get you started on some fun experiments. You can of course take the gtk4-demo code as a starting point.

You can debug it

Apart from widgets, the shader support is fully integrated. The GTK inspector can handle shader nodes like any other render nodes, you can serialize them and e.g. load the resulting file in gtk4-node-editor:

If you need to see the input that GTK sends to the shader compiler,  setting the environment variable

GDK_DEBUG=shaders

can be helpful.

Whats next?

After this GL adventure we’ll now focus on landing more of the new accessibility infrastructure.

It has been a month since we released GTK 3.99, high time for another snapshot. Here it is: https://download.gnome.org/sources/gtk/3.99/gtk-3.99.1.tar.xz

This snapshot is focused on polish and completion.

Loose ends

We’ve tied up a number of loose ends in our APIs.

The most user-visible change was probably the simplification of the button class hierarchy. Instead of deriving GtkCheckButton from GtkToggleButton, they are now two independent widgets, and they both can be grouped to be mutually exclusive (aka as “radio group”). In this new setup, GtkRadioButton is not really needed anymore, and therefore gone.

The API of our new list widgets (GtkListView and GtkGridView) has seen some small tweaks as well. We are now explicitly requiring the models to be of type GtkSelectionModel, to make it clear that the widgets handle selections.  And we’ve gotten rid of the extra “with_factory” constructors, and just take a nullable factory argument in new(), leaving us with

GtkWidget * gtk_list_view_new (GtkSelectionModel  *model,
                               GtkListItemFactory *factory);

As more of an  API cleanup, we’ve dropped all the defines for CSS style classes – which style classes our widgets support is defined in their documentation, and these extra defines were not really well-defined or useful.

Our theme is now rounding the corners of the frame that is drawn by GtkFrame widgets. This required us to make frames clip their children – not really an API change, but a behavior change that is worth mentioning.

More demos

A lot of effort has gone into gtk4-demo over the past month.

We have modernized the source code highlighting. We are now using the highlight commandline utility. Among other things, this allows us to have syntax highlighting for xml and css, as well as dark theme support.

The list of demos has better filtering and a better appearance. The new look is one of a few predefined list styles that Adwaita supports now: rich list, navigation sidebar and data table.

 

We have dropped a few outdated demos from gtk4-demo, and polished many of the existing ones. Here is how our Drag-and-Drop demo looks now:

A number of new demos have been added as well. Here is the new demo for layout managers and transformations:

Performance, and other bugs

Many bugs have been squashed; thanks to our eager testers and bug reporters.

A long-standing issue that we finally tracked down recently caused our GL renderer to get clipping wrong in the presence of non-trivial projective transformations. This has now been corrected (and the result can be seen in the transformation demo above).

As part of the highlighting improvements that have been mentioned before, gtk_text_view_buffer_insert_markup() has been made much faster. This improvement only happened because the highlight utility can produce Pango markup. Kudos to whoever implemented that!

Another performance problem that we’ve addressed is the loading time of the font chooser dialog on systems with many fonts. We are now populating the font list incrementally. Apart from this change, the investigation has led to performance improvements in fontconfig and Pango that will benefit any user of those libraries.

Can I port already?

The answer is: yes!

Now is a great time to take a look at GTK4, start porting your app, and give us feedback on our APIs, new and old. We are also eager to see what ideas you have for using GTK4 in unexpected ways – the few demos we’ve shown above can maybe give you some inspiration.

Whats next?

We are looking to land the at-spi backend for our new accessibility interfaces soon; it should be included in the next GTK snapshot.

This week, we’re releasing GTK 3.99, which can only mean one thing: GTK4 is getting really close!

Back in February, when 3.98 was released, we outlined the features that we wanted to land before making a feature-complete 3.99 release. This was the list:

• Event controllers for keyboard shortcuts
• Movable popovers
• Row-recycling list and grid views
• Revamped accessibility infrastructure
• Animation API

How have we done?

We’ve dropped animation API from our 4.0 blocker list, since  it requires more extensive internal restructuring, and we can’t complete it in time. But all the other features have found their way into the various 3.98.x snapshots, with the accessibility infrastructure being the last hold-out that landed very recently.

Some of the features have already been covered here, for example Movable popovers and  Scalable Lists. The others will hopefully receive some detailed review here in the future. Until then, you can look at Emmanuele’s GUADEC talk if you are curious about the new accessibility infrastructure.

What else is new ?

One area I want to highlight is the amount of work that has gone into fleshing out the new scalable list infrastructure. Our filter and sort models do their work incrementally now, so the UI can remain responsive while large lists are getting filtered or sorted in the background.

A new macOS GDK backend has been merged. It still has some rough corners that we hope to smooth over between now and the 4.0 release.

And many small regressions have been fixed, from spinbutton sizing to treeview cell editing to autoscrolling to Inspector navigation to slightly misrendered shadows.

Can I port yet?

GTK 3.99 is the perfect time to take a first look at porting applications.

We are very thankful to the early adopters who have braved the 3.96 or 3.98 snapshots with trial ports and provided us with valuable feedback. With so many changes, it is inevitable that we’ve gotten things wrong in the API, and getting that feedback while we can still address things will really help us. Telling us about things we forgot to cover in the docs, missing examples or gaps in the migration guide is also very much appreciated.

We are aware that some porting efforts will be stopped short by indirect dependencies on GTK 3. For example, if you are using a webkit webview or GtkSourceView or vte, you might find it difficult to try out GTK 4.

Thankfully, porting efforts are already well underway for some of these libraries. Other libraries, such as libgweather will need some work to separate their core functionality from the GTK 3 dependency.

Can I help?

As mentioned in the previous section any feedback on new APIs, documentation and the porting guide is very welcome and helpful.

There are many other areas where we could use help. If you are familiar with OS X APIs, you could make a real difference in completing the macOS backend.

We have also started to integrate an ANGLE-based GL renderer, but our shaders need to be made to work with EGL before we can take advantage of it. Help with that would be greatly appreciated.

Whats next?

We are committed to releasing GTK 4 before the end of year. Between now and then, we are doing more work on accessibility backends, improving the macOS backend, writing documentation, and examples.

When we released 3.98.0, we promised more frequent snapshots, as the remaining GTK 4 features are landing. Here we are a few weeks later, and 3.98.1 and 3.98.2 snapshots have quietly made it out.

So, what is new ?

Features

There is still work left to do, but a few more big features have landed.

The first is that we have completed the reimplementation of GtkPopovers as xdg-popup surfaces, and split up the GdkSurface API into separate GdkToplevel and GdkPopup interfaces (there’s a GdkDragSurface interface too), which reflect the different roles of surfaces:

• Toplevels are sovereign windows that are placed by the user and can be maximized, fullscreened, etc.
• Popups are positioned relative to a parent surface and often grab input, e.g. when used for menus.

In GTK, popovers have lost their :relative-to property, since they are now part of the regular hierarchy like any other widget, and GtkWindow has lost its :window-type property, since all instances of GTK_WINDOW_POPUP have been converted to popovers, and windows are just used for proper toplevels.

Another major feature is the new infrastructure for keyboard shortcuts. In the past, GTK has had a plethora of APIs to implement key bindings, mnemonics and accelerators. In GTK 4, all of this is handled by event controllers. GtkShortcutController is a bit more complex than typical event controllers, since it handles all the different kinds of shortcuts with a unified API.

Thankfully, most of the complexity is hidden. For widget implementors, the important APIs are the variants of gtk_widget_class_add_shortcut(), which are used to add key bindings. For applications, mnemonics and global accels (with gtk_application_set_accels_for_action()) work the same as before. Additionally, it is possible to create shortcut controllers and shortcuts in ui files.

A set of smaller features has landed in the form of a few GtkTextTag properties that expose new pango features such as overlines, visible rendering of spaces and control over hyphenation. These can now be controlled in a GtkTextView via tags. In entries, they can already be controlled by directly adding pango attributes.

Completions

When I wrote about 3.98, I said that the Drag-and-Drop refactoring was complete. That turned out to be not quite correct, and another round of DND work has landed since. These changes were informed by developer feedback on the Drag-and-Drop API. Yay for user testing!

We introduced separate GtkDropTarget and GtkDropTargetAsync event controllers, with the former being simplified to avoid all async API, which makes it very easy to handle local cases.

We also cleaned up internals of the DND implementation to group DND events into event sequences, handle them in just the same way as normal motion events,  and introduced GtkDropControllerMotion, which is an event controller that is designed to handle things like tab switching during a DND operation.

Finally, we could remove the remnants of X11-style property and selection APIs; GtkSelectionData and GdkAtom are gone.

Cleanups and fixes

As always, there’s a large number of smaller cleanups and fixes that have happened.

The biggest group of cleanups happened in the file chooser, where a number of marginally useful APIs (extra widgets, overwrite confirmation, :local-only, GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER, etc) have been dropped. To make up for it, the portal implementation of the native file chooser supports selecting folders now.

Another big cleanup was that GdkEvent is now an immutable boxed type. This was mainly an internal cleanup; the effect on application-level APIs is small, since event controllers have replaced direct event handling for the most part.

One new such event controller is GdkEventControllerFocus, which was split of from the key event controller to provide just focus handling.

GtkMenuButton lost its ability to have mnemonics when it was turned from a GtkButton subclass into a plain widget. This functionality has been reinstated, with a :use-underline property.

The HighContrast and HighContrastInverse themes that are included in GTK are now derived from Adwaita, for a much reduced maintainance burden and improved quality. Trying these themes out in gtk4-widget-factory is now easier, since we added a style menu.

The new HighContrast theme has also been backported to GTK 3.

Whats ahead

We will continue our snapshots and hope to get more developer feedback on the new APIs and features described above.

Here are things that we still want to integrate before GTK 4:

• Row-recycling list and grid views
• Revamped accessibility infrastructure
• Animation API

If you want to follow the GTK 4 work, go here.

A few days ago, I’ve released a GTK 3.98 tarball. This is another step towards GTK 4. It is a little bit behind schedule, and does not quite include all the things we wanted to get into it, but it gets a lot closer to what we want to ship in GTK 4.

Almost 9 months have passed since the 3.96 snapshot, so there are quite a few new things to look at. Too many to cover them all, but here are some highlights:

Performance

The GL renderer has seen a steady flow of optimizations and performance improvements.

After the Westcoast hackfest last year, the GtkTextView scrolling performance has been greatly improved by making it cache render nodes for the visible range. At the same hackfest, the text caret blinking was changed to be smoothly animated, which is not relevant for performance at all, but looks cool.

Since the new year, a big focus has been on improving the performance of the CSS machinery. The CSS value implementation has been optimized to avoid computing values whenever possible. CSS lookups are using a Bloom filter now. And the IO for icon loading has been moved to a thread.

Most of the recent work was made possible by the sysprof profiling support that was added after the performance hackfest, and has recently been enhanced to report more information. To use it, simply start a GTK application with GTK_TRACE=1 in the environment, and load the resulting syscap file with sysprof.

DND

The DND refactoring has been completed. The GTK API for DND has been turned into event controllers: GtkDragSource and GtkDropTarget. Support for file transfers via file transfer portal has been added for both DND and the clipboard.  The underlying new infrastructure for data transfers has been covered in detail before.

GDK

The move of GDK towards Wayland concepts is continuing. This cleanup is not 100% complete yet.

Child surfaces have been removed. GDK only supports toplevel and popup surfaces now. The client-side window implementation has been removed too. Global positions and related APIs such as gdk_surface_move() are no longer available.

Grabs are no longer exposed as API. As a replacement, popup surfaces can be configured to hide on outside clicks.

XI2 is now mandatory when building the X11 backend, and support for the xim input method has been removed in favor of IBus.

The Wayland backend no longer relies on libwayland-cursor to load cursor themes, and loads individual cursors on demand.

GTK removals

Many classes have been made explicitly non-subclassable, and the widget hierarchy has been simplified, by making widgets derive directly from GtkWidget where possible.

GtkMenu, GtkMenuBar, GtkToolbar and related classes have been removed. They are being replaced by GMenu and popover-based variants. Popover menus can now do traditional, nested menus, and also show accelerators.

Context menus are no longer created with ::populate-popup signals, but also use menu models and actions. Creating those actions has been made easier with APIs like gtk_widget_class_install_action(), to create them in class_init.

GtkGestureMultiPress has been renamed to GtkGestureClick, to make it more obvious what this event controller is for.

GTK additions

We did not just remove things. Some new things have been added too.

The GtkNative interface has been introduced for widgets that have their own surface. This has been split off from the GtkRoot interface, which is exclusively for toplevel widgets without a parent.

A constraint-based layout manager has been added. It would be great to see people try this out. Please give us feedback if you do.

GtkTextView and other text widgets have gained a simple undo stack that can be used with Ctrl-Z.

The Emoji chooser widget has been made public.

Whats ahead

After 3.98, I’m planning to do more frequent snapshots, as the remaining outstanding items are landing. What are those items, you are asking ?

Here are the things that we still want to integrate before GTK 4:

– Event controllers for keyboard shortcuts
– Movable popovers
– Row-recycling list and grid views
– Revamped accessibility infrastructure
– Animation API

 

 

This week, we released GTK 3.96.0. Again, it has been a while since the last release, so it is worth summarizing whats new in this release. There is really too much here to cover it all, so this post will only highlight the most important changes.

This release is another milestone on our way towards GTK 4. And while there are still some unfinished things, this release is much closer to we hope to achieve with GTK 4.

GSK

GSK has seen a number of bug fixes and new tests that are made much easier using a new debug tool, gtk4-node-editor. It can load and display serialized render node trees, such as this one that was saved from the GTK inspector, and compare the output of different renderers.

The 3D transformation support has been brought up to the level where we can do animated transitions like the cube spin below.

GDK

The trend to move toward Wayland inspired APIs has continued, with more X11-only apis being moved to the X11 backend or just removed. Use of child surfaces and global coordinates has been greatly reduced, but this work remains incomplete.

The refactoring of Drag-and-Drop has also continued, with the introduction of GdkDrag and GdkDrop objects. The GTK part of this refactoring is still incomplete.

Events have been simplified and are now used just for input. Other event have been replaced by signals and properties on GdkSurface. In detail, expose events have been replaced by the ::render signal, configure events have been replaced by the ::size-changed signal. Map events have been replaced by the :mapped property, and gdk_event_handler_set() has been replaced by the ::event signal.

The Wayland backend has gained support for the Settings portal for GtkSettings, and uses the text-input-unstable-v3 protocol for its input method support.

GTK

Widgets

One big change for custom widgets is the introduction of GtkLayoutManager, which is a new delegate object that takes over size allocation. Layout managers can optionally use layout children for holding layout properties. This replaces the layout-related child properties in GTK containers such as GtkBox or GtkGrid.

A number of layout managers are available:

• GtkBinLayout, for simple single-child containers
• GtkBoxLayout, for children that are arranged linearly
• GtkGridLayout, for children that are arranged in a grid
• GtkFixedLayout, for freely positioned and transformed children
• GtkCustomLayout, as a quick way to turn traditional measure and size_allocate vfuncs into a layout manager

More layout manager implementations will appear in the future. Most prominently, work is underway on a constraints-based layout manager.

GtkAssistant, GtkStack and GtkNotebook have publicly
accessible page objects for their children. The page objects
are also exposed via a list model. They non-layout related child properties of these containers have been converted into regular properties on these page objects.

Since all existing child properties have been converted to regular properties, moved to layout properties or moved to such page objects, support for child properties has been dropped from GtkContainer.

The core GtkEntry functionality has been moved into a new GtkText widget, which also implements an expanded GtkEditable interface. All existing entry subclasses in GTK have been turned into GtkEditable implementations wrapping a GtkText widget. This also includes a new GtkPasswordEntry.

Other Changes

GTK widgets can transform their children using projective linear
transformations. This functionality is available in CSS and
as a GskTransform argument to gtk_widget_allocate. GtkFixed is
the first container that exposes this functionality. For further examples,
see the swing transition of GtkRevealer, the rotate transitions
of GtkStack or the Fixed Layout example in gtk4-demo.

A number of list models have been introduced, for internal use
and as public API: GtkMapListModel, GtkSliceListModel, GtkSortListModel, GtkSelectionModel, GtkSingleSelection. These will become more widely used when we introduce a list model-based GtkListView.

GtkBuilder can specify object-valued properties inline, instead of referring to them by ID, and the simplify command of gtk4-builder-tool has gained an option to automatically convert GTK 3 UI definition files to GTK 4.

Coming soon

For more information on the things that are still still coming for GTK 4, find us on Discourse, IRC, or look here.

Today, we released GTK+ 3.94.0. Again, it has been a while since the last release, so it is worth summarizing whats new in this release. There is really too much here to cover it all, so this post will only highlight the most important changes.

This release is another milestone on our way towards GTK+ 4. And while there are still some unfinished things, this release is much closer to we hope to achieve with GTK+ 4.

GSK

The Broadway backend now has a GskRenderer, so the future for Broadway looks much better.

We introduced a new type of render node, GskOffsetNode, which is a simplified GskTransformNode and takes over the job of translating content as we move up and down the render node tree. With this change, we are now able to cache render nodes for widgets over multiple frames, and reposition them if necessary.

We also introduced GskDebugNodes, which take over node names, and let us simplify some of the GTK+ apis for creating render nodes.

When falling back to cairo for rendering, we now use recording surfaces instead of image surfaces, so we can replay the rendering at a different scale.

An important new operation is gsk_render_node_diff to compare two render node trees (see below for more on this).

GDK

Following the general trend of aligning the GDK apis with Wayland instead of X, GdkWindow was renamed to GdkSurface.

The GdkTexture api has been refined, with new GdkMemoryTexture and GdkGLTexture subclasses, and a powerful new abstraction, GdkPaintable, has been introduced.

A GdkPaintable represents an object that can be painted anywhere at any size without requiring any sort of layout. This is inspired by similar concepts elsewhere, such as ClutterContent, HTML/CSS Paint Sources or SVG Paint Servers. To show off the power of this concept, a few new demos have been added in gtk4-demo:

The DND code continues to see major refactorings. It now uses the same content-provider infrastructure that was introduced in 3.93 for clipboard handling, and it has separate objects for the source and target side of a DND operation. More changes will be coming here.

GTK

widgets

GTK+ has gained support for showing videos, with the GtkVideo and GtkMediaControls widgets, and there is also a new GtkPicture widget to split off image viewing from GtkImage (which is really about icons).

GtkFontChooser allows tweaking OpenType features and font variations, and Ctrl-Shift-e for color Emoji input has been replaced with completion that can be enabled with the GtkEntry::enable-emoji-completion property.

Input

The event-specific signals in GtkWidget continue to disappear. At this point only ::event is left, but it will go away too. Instead, we are using event controllers, and several new ones have been added to cover all needed events:

• GtkEventControllerMotion
• GtkEventControllerKey
• GtkGestureStylus

To make this transition easier, it is now possible to create event controllers in ui files.

Wayland has its own platform input method, based on the Wayland text protocol.

Drawing

The ::draw signal has been removed, all widgets have to implement ::snapshot. They can now create their own GtkSnapshot instances for intermediate rendering. Clipping is no longer applied on the GTK+ level – widgets are free to draw outside their allocation, if that is what is required.

Widget invalidation has been changed, it now works by discarding the cached render nodes of invalidated widgets, and recreating the missing parts of the render node tree.

For finding the region that needs to be redrawn, GTK+ diffs the render node trees of the previous and the current frame, and applies some heuristics to keep the number of rectangles from growing too large.

The GTK+ inspector lets you track invalidations, which you can see in action here:

Other changeS

GTK+ no longer supports generic loadable modules. Input methods, print backends and media backends have been converted to GIOModules and extension points.

The platform im modules (i.e. the Windows, Wayland, Broadway im contexts)  are always included and will be enabled by default on their platform.

The Vulkan support in GDK can now use a particular device that is specified by the GDK_VULKAN_DEVICE environment variable. Use GDK_VULKAN_DEVICE=list to see all availble devices.

Try it out

With GTK+ 3.94.0, it should be possible to start porting applications. The documentation has an initial porting guide.