Wayfire 0.8.0 announcement
Hello everyone! It has been nearly three years since I last wrote to this blog. Fortunately, that does not mean Wayfire’s development has stopped! Quite the opposite, in fact I am happy to announce the release of Wayfire 0.8.0. There have been many changes and plugin API breakages since the Wayfire 0.7.x series, so I will try to summarize the important changes in the following paragraphs.
User-facing changes
First, let us take a look at the user-facing changes and new features that were added in this release:
Workspace sets (Wayfire PR #1797)
Workspace sets are a new feature provided by the wsets plugin. A workspace set is the grid of workspaces on one output. Up until now, Wayfire always had one workspace set (albeit it wasn’t called like this) per output. With the recent changes, it is possible to have multiple workspace sets on each output and switch between them. The end result is very similar to how Sway’s workspaces work: the plugin numbers them from 1 to N, and at any given moment you can display any of the workspace sets on any of your outputs (however, each workspace set can be visible on at most one output at a time). Check the YouTube video to get a better sense of what they provide (the recording contains two Wayfire outputs side-by-side):
The purpose of workspace sets is to have a dedicated set of normal workspaces for different activities the user does on their computer. For example, I have one workspace set (containing a 2x2 workspace grid) dedicated to Wayfire, where I have Wayfire’s source code, GitHub issues, wlroots, etc. There is another workspace set dedicated to a project I am working on for university, and so on. Of course, a similar effect could be achieved with a single bigger workspace grid, but having a 5x5 workspace grid quickly becomes difficult to navigate.
It should also be noted that workspace sets can be moved between outputs, which is something generally impossible with normal workspaces. I use this for example when switching between working on my laptop and an external monitor - it is just a matter of showing the workspace set on the new monitor.
IPC socket (Wayfire PR #1472, PR #1821)
A frequent request for Wayfire was the ability to control it via IPC commands. With this release, Wayfire now provides a socket that clients can use for this purpose. To use it, make sure to enable the ipc plugin (it should be first in the list of plugins). The ipc plugin itself does not implement any IPC commands, instead, it only provides a generic framework for other plugins to extend. The ipc-rules plugin provides a few basic window-management commands and can be used to substitute the window-rules plugin with a custom user-provided script, see the Python example for more information.
The plan for the future is to extend the ipc-rules plugin to support more commands and to report more events to the IPC clients. In addition, some other plugins provide their functionality as IPC commands, for example wm-actions and grid. Lastly, there is a new framework to allow all plugin bindings to be callable from an IPC script - for example after this commit, the scale plugin can be activated from the IPC socket.
If you want to use the IPC socket, but the currently provided commands are not enough for your use-case (which is likely!), feel free to reach out to discuss how to extend the existing IPC support.
Smaller changes
Some smaller, but important items from the git log:
- Expo workspaces can now be navigated with the keyboard: PR #1156
- Animations for the simple-tile plugin: PR #1071
- Vswitch plugin has bindings for moving to a particular workspace and to last workspace: PR #1199, PR #1371. Some bindings were renamed:
binding_win_*now becomeswith_win_*. - Multiple protocols which were previously provided by core have been moved to plugins:
wayfire-shell(PR #1715),foreign-toplevel,gtk-shell(PR #1678). Most likely, you will want to enable those in yourwayfire.ini. - Added support for the xdg-activation-v1 protocol: PR #1898
There were of course many, many other small fixes and added options and PRs, which cannot be all presented here. See the full git changelog for details :)
wf-shell
Thanks to multiple contributors, there have also been numerous improvements to the default panel, wf-panel, part of wf-shell:
- Huge thanks to a new contributor @NamorNiradnug, who implemented:
- Thanks to @soreau for implementing a logout interface: PR #100
Plugin API changes
The focus of the 0.8.0 release was to clear the technical debt which has accumulated in core over the time. As a result, many APIs were refactored and some were completely rewritten, resulting in many breaking changes for plugins. On the upside, with most of the glaring problems in the API fixed, plugin authors can expect less (at the very least, much less severe) API changes in the future.
The following is a summary of the big items, many of which also provide new or improved capabilities for plugins (and, unfortunately, expose more of the complexity at times).
Scenegraph (Wayfire PR #1501)
Until now, Wayfire has had very simple algorithm for rendering and input handling. Core had a list of outputs, and each output had a list of layers and views in them. While the basic structure has remained roughly the same, Wayfire 0.8.0 has a single structure called the scenegraph, which organizes all of these in a structure with a single interface. The scenegraph can also be used to repalce custom renderers and input grabs used in previous versions of Wayfire. See the wiki page on this topic for an introduction into the technical aspects of it.
View Interface (Wayfire PR #1370, PR #1704)
Over time, Wayfire’s central type - views, which represent application windows - has accumulated too many methods, fields and responsibilities. As a part of the refactoring effort, the input and rendering aspects of this interface have been moved to the scenegraph nodes associated with a given view. The view interface itself has been split in two - ‘generic’ views, which represent any type of window, including backgrounds, panels, etc. and a specialized subclass toplevel views, which represent toplevel windows, which can be moved, resized, maximized, etc. See the wiki for more details.
Transactions (Wayfire PR #1704)
Tiling plugins like simple-tile need a way to resize multiple toplevels synchronously. In addition, certain changes in toplevel states (for example fullscreening and resizing to the full output size) belong logically together. In the Wayland protocol, these concepts usually are represented by using commits which group together related changes to an object. In Wayfire 0.8, we also have a similar system on the server side - transactions. They can be used to update multiple toplevels (or in general, transaction objects) and their properties atomically.
Another possible application of transactions is providing out-of-compositor decorations, like Emerald for Compiz: with transactions, a plugin can synchronize the state of the decoration and the main window. However, support for this has only barely reached the proof-of-concept stage. For the interested in continuing this development, a starting point can be found here.
Smaller changes
There were also multiple smaller fixes and updates to the API, a non-exhaustive list of which is here:
- Plugins now have one single instance, instead of one instance per output (use
wf::per_output_plugin_t<>as a helper for achieving the old behavior): PR #1674 - Keyboard focus is now tracked globally, instead of per-output: PR #1913
- The signals API has been rewritten, so that it operates on types instead of strings for the signal names, reducing their overhead: PR #1495
Conclusion
Thank you for reading the blog to the end :) The latest Wayfire 0.8.0 release contains many breaking changes, but also some exciting new features. Do not hesitate to open bug reports if you notice any regressions if you are upgrading from the 0.7.x series. Last but not least, many thanks to everyone who has contributed code or has tested the git version of Wayfire!