Full Wayland support in GTK+

GTK+ already has a functional Wayland backend, but several pieces of functionality need to be completed before it is ready for prime time.

Many of the issues listed here apply to the clutter Wayland backend as well.

Also see the "Known Issues" section in Waylands own GTK+ documentation.

How to try GTK+ under Wayland

Fedora

In Fedora 19, GTK+ has been built with Wayland and X11 support, so all you need to try it is a Wayland compositor. Weston, the reference Wayland compositor, is available in the weston package.

$ yum install weston
$ weston &

This will run weston as an X client. clicking on the terminal icon in the weston panel will give you a terminal window. Inside there, you can run GTK+ applications like this:

$ GDK_BACKEND=wayland
$ export GDK_BACKEND
$ gtk3-demo

Client-side decorations

Under Wayland, it is preferred that clients render their own window decorations. Since gnome-shell will need to keep support for decorating X clients, it would be good if GTK+ and gnome-shell could share the css theming.

The goal here is to recreate the Adwaita-style decorations, including

• minimize/maximize/close buttons

• window title

• hide-title-when-maximized

• fullscreen

• maximizing

• tiling 696001

• rounded corners

• dark theme variant

• double-click action on the titlebar

• invisible borders for resizing

• shadows

• Opaque region 696805

• Input region 698072

• support for title buttons

Another goal we want to achieve with client-side decorations is to allow application controls in the titlebar, such as Previous/Next buttons for assistants, or Close buttons for dialogs.

Initial support for this has been developed in bug 694381 and committed. Some more work is needed.

Tasks here:

• Review and merge the branch

• Add any missing features from the list above

• Fix problems with client-side decorations: 696017, 696341, 697679, 697696

• Review the css support and sync it with gnome-shell

• Add symbolic icons 697930

Copy/Paste support

The GTK+ APIs for this are spread out over GdkSelection, GtkSelection and GtkClipboard. Both GdkSelection and GtkSelection are closely tied to the way selections work in X. GtkClipboard should be the cross-platform abstraction for copy/paste that can be supported under Wayland.

Relevant Wayland interfaces: wl_data_device_manager, wl_data_offer, wl_data_source Relevant bug: #672358

Tasks here:

• Add a GtkClipboard interface that allows to have both X11 and Wayland clipboard support at the same time

• Move X-specific selection code into the X backend

• Add backend-specific GtkClipboard implementations

• Clarify our stance on the PRIMARY selection, and either implement it for Wayland, or cleanly ignore it 695514. See Initiatives/Wayland/PrimarySelection

Drag-and-Drop support

The DND protocol in Wayland is similar to what GTK+ already supports. It should be possible to add Wayland support without changing APIs.

Relevant Wayland interfaces: wl_data_device_manager, wl_data_device

Tasks here:

• Drop the non-working Motif DND code from the X backend: #695475

• Add an implementation of the Wayland DND protocol in the Wayland backend 697855

• Hook it up to the GTK+ level

Popups and grabs

Wayland does not have explicit grabs. GTK+ commonly uses grabs when showing override-redirect windows that want exclusive control of the pointer. Instead, Wayland has a concept of popup windows that get hidden automatically when they 'lose' the pointer. Representing this concept in GTK+ will require some API changes.

For now, the Wayland backend is working using heuristics to use popups when appropriate, which makes menus and combo box popups mostly work.

Tasks here:

• Add a concept of 'popup window' to GDK (unfortunately, we already have GTK_WINDOW_POPUP). It can be implemented with grabs under X, and with the native concept of the same name under Wayland. This is being developed now on https://git.gnome.org/browse/gtk+/log/?h=wip/garnacho/gdkseat under the name GdkSeat

• Port GTK+ to use the new GdkSeat apis

• Deprecate grabs
• Support submenus, once Wayland gains the concept of nested popup windows

Window positioning

Another problem with the GTK+ APIs around override-redirect windows is that Wayland does not give clients access to window positions, so the positioning callbacks that are used e.g. in gtk_menu_popup() won't work anymore.

A Wayland API for positioning windows has been proposed here: http://lists.freedesktop.org/archives/wayland-devel/2013-February/007340.html

Tasks here:

• Come up with an alternative API for window positioning
• Deprecate APIs that rely on global positions

Keyboard layouts

The keymap support in the Wayland backend is greatly improved in 3.9. Most important pieces of functionality have been implemented now:

• groups

• virtual modifiers

• direction

Weston does not support changing keyboard layouts at runtime, so this functionality has not been tested.

Tasks here:

• Rework the GDK keyboard object model 696339

• Implement GdkKeymap::keys-changed and test it

• Implement other missing functionality in GdkWaylandKeymap

Input methods

Support the Wayland text protocol. 698307

XSettings

The XSettings support in the Wayland backend is rudimentary. The supported settings are just hardwired to default values. XSettings was not a great success story in terms of adoption by other environments. One possible way forward would be to just drop the concept and instead port GtkSettings to use !GSettings directly. Alternatively, a simple interface could be provided by the compositor for these settings.

For now, the Wayland backend has been changed to use GSettings directly, when available.

Tasks here:

• Decide which way to go - see Hackfests/GTK2013 for an evaluation of existing settings

• Implement it; depending on whats decided that either means implement the settings interface in the Wayland backend, or port GtkSettings

Frame synchronization

GTK+ recently gained support for frame synchronization with the compositor. This is implemented under X using a pair of XSync counters. Equivalent Wayland functionality has been implemented in the GDK backend in 3.9.

Tasks here:

• Implement the extension in the compositor. May not actually be necessary
  • A lot of this is actually taken care of by having explicit frame requests/boundaries, unlike X where you have to guess. There's also a 'frame' event which can be used to drive display to some extent, but there are a number of issues around this; in particular, right now it's used both as a hint that the frame has been integrated into the scene (e.g. to drive animation clocks) and will be displayed, and as a hint that the frame _was_ displayed and actually hit the screen. It looks like we need both - the latter is required for media usecases - so this is going to need some work in the core. -daniels

• Add support for it in the Wayland backend

Miscellaneous

• Implement animated cursors 696429

• Complete implementation of output information apis 692871

• Add a way for applications to opt out of using certain backends (e.g. apps that still have X dependencies need to say 'always use X', even if GTK+ is built with both X and Wayland) 694465

• Build the Wayland backend by default