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
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
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
dark theme variant
double-click action on the titlebar
invisible borders for resizing
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.
Review and merge the branch
Add any missing features from the list above
Review the css support and sync it with gnome-shell
Add symbolic icons 697930
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
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
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
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.
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
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
- Come up with an alternative API for window positioning
- Deprecate APIs that rely on global positions
The keymap support in the Wayland backend is greatly improved in 3.9. Most important pieces of functionality have been implemented now:
Weston does not support changing keyboard layouts at runtime, so this functionality has not been tested.
Rework the GDK keyboard object model 696339
Implement GdkKeymap::keys-changed and test it
Implement other missing functionality in GdkWaylandKeymap
Support the Wayland text protocol. 698307
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.
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
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.
- 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
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