KWin on KDE Blogs

Cursor Size Problems In Wayland, Explained

Jin Liu — Wed, 09 Oct 2024 09:36:02 +0000

I've been fixing cursor problems on and off in the last few months. Here's a recap of what I've done, explanation of some cursor size problems you might encounter, and how new developments like Wayland cursor shape protocol and SVG cursors might improve the situation.

(I'm by no means an expert on cursors, X11 or Wayland, so please correct me if I'm wrong.)

Why don't we have cursors in the same size anymore?

My involvement with cursors started back in the end of 2023, when KDE Plasma 6.0 was about to be released. A major change in 6.0 was enabling Wayland by default. And if you enabled global scaling in Wayland, especially with a fractional scale like 2.5x, cursor sizes would be a mess across various apps (the upper row: Breeze cursors in Plasma 6.0 Beta 1, Wayland, 2.5x global scale, the lower row: Same cursors in Plasma 6.0):

So I dug into the code of my favorite terminal emulator, Kitty, which at the time drew the cursor in a slightly smaller size than it should be (similar to vscode in the above image). I gained some understanding of the problem, and eventually fixed it. Let me explain.

How to draw cursors in the same size in different apps?

In X11, there used to be a standard set of cursors, but nowadays most apps use the XCursor lib to load a (user-specified) cursor theme and draw the cursor themselves. So in order to have cursors in the same theme and size across apps, we need to make sure that:

Apps get the same cursor theme and size from the system.
Apps draw the cursor in the same way.

The transition to Wayland created difficulties in both points:

1. Get the same cursor theme and size from the system

It used to be simple in X11: we have Xcursor.size and Xcursor.theme in xrdb, also XCURSOR_SIZE and XCURSOR_THEME in environment variables. Setting them to the same value would make sure that all apps get the same cursor theme and size.

But Wayland apps don't use xrdb, and they interpret XCURSOR_SIZE differently: in X11, the size is in physical pixels, but in Wayland it's in logical pixels. E.g., if you have a cursor size 24 and global scale 2x, then in X11, XCURSOR_SIZE should be 48, but in Wayland it should be 24.

The Wayland way is necessary. Imagine you have two monitors with different DPI, e.g. they are both 24" but monitor A is 1920x1080, while monitor B is 3840x2160. You set scale=1 for A and scale=2 for B, so UI elements would be the same size on both monitors. Then you would also want the cursor to be of the same size on both monitors, which requires it to have 2x more physical pixels on B than on A, but it would be the same logical pixels.

So Plasma 6.0 no longer sets the two environment variables, because XCURSOR_SIZE can't be simultaneously correct for both X11 and Wayland apps. But without them and xrdb, Wayland apps no longer have a standard way to get the cursor theme and size. Instead, different frameworks / toolkits have their own ways. In Plasma, KDE / Qt apps get them from the Qt platform integration plugin provided by Plasma, GTK4 apps from ~/.config/gtk-4.0/settings.ini (also set by Plasma), Flatpak GTK apps from the GTK-specific configs in XDG Settings Portal.

The last one is particularly weird, as you need to install xdg-desktop-portal-gtk in order fix Flatpak apps in Plasma, which surprised many. It might seem like a hack, but it's not. Plasma officially recommends installing xdg-desktop-portal-gtk, and this was suggested by GNOME developers.

But what for 3rd-party Wayland apps besides GTK and Qt? The best hope is to read settings in either the GTK or the Qt way, piggy-backing the two major toolkits, assuming that the DE would at least take care of the two.

(IMHO either Wayland or the XDG Settings Portal should provide a standard way for apps to get the cursor theme and size.)

That was part of the problem in Kitty. It used to read settings from the GTK portal, but only under a GNOME session. I changed it to always try to read from the portal, even if under Plasma. But that's not the end of the story...

2. Draw the cursor in the same way

It's practically a non-issue in X11, as the user usually sets a size that the cursor theme provides, and the app just draws the cursor images as-is. But if you do set a cursor size not available in the theme (you can't do that in the cursor theme settings UI, but you can manually set XCURSOR_SIZE), you'll open a can of worms: various toolkits / apps deal with it differently:

Some just use the closest size available (Electron and Kitty at the time), so it can be a bit smaller.
Some use the XCursor default size 24, so it's a lot smaller.
Some scale the cursor to the desired size, and the scaling algorithm might be different, resulting in pixelated or blurry cursors; Also they might scale from either the default size or the closest size available, resulting in very blurry (GTK) or slightly blurry (Qt) cursors.

The situation becomes worse with Wayland, as the user now specifies the size in logical pixels, then apps need to multiply it by the global scale to get the size in physical pixels, and try to load a cursor in that size. (If the app load the cursor in the logical size, then either the app or the compositor needs to scale it, resulting in a blurry / pixelated cursor.) With fractional scaling, it's even more likely that the required physical size is not available in the theme (which typically has only 2~5 sizes), and you see the result in the picture above.

One way to fix it (and why I didn't do)

It can be fixed by moving the "when we can't load cursors in the size we need, load a different size and scale it" logic from apps / toolkits to the XCursor lib. When the app requests cursors in a size, instead of returning the closest size available, the lib could scale the image to the requested size. So apps would always get the cursor in the size they ask for, and their own different scaling algorithms won't get a chance to run.

Either the default behavior can be changed, or it can be hidden behind a new option. But I didn't do that, because I felt at the time that it would be difficult to either convince XCursor lib maintainers to make a (potentially breaking) change to the default behavior, or to go around convincing all apps / toolkits to use a new option.

My fix (or shall we say workaround)

Then it came to me that although I can't fix all these toolkits / apps, they seem to all work the same way if the required physical size is available in the theme - then they just draw the cursor as-is. So I added a lot of sizes to the Breeze theme. It only has size 24, 36 and 48 at the time, but I added physical sizes corresponding to a logical size 24 and all global scales that Plasma allows, from 0.5x to 3x, So it's 12, 18, 24 ... all the way to 72.

It was easy. The source code of the Breeze theme is SVG (so are most other themes). Then a build script renders it into images using Inkscape, and packages them to XCursor format. The script has a list of the sizes it renders in, so I added a lot more.

And it worked! If you choose Breeze and size 24, then (as in the bottom row in the picture above) various apps draw the cursor in the same size at any global scale available in Plasma.

But this method has its limitations:

We can't do that to 3rd-party themes, as we don't have their source SVG.
It only works if you choose the default size 24. If you choose a different size, e.g. 36, and a global scale 3x, then the physical size 36x3=108 is not available in the theme, and you see the mess again. But we can't add sizes infinitely, as explained in Vlad's blog, the XCursor format stores cursor images uncompressed, so the binary size grows very fast when adding larger sizes.

Both limitations can be lifted with SVG cursors. But before getting to that, let's talk about the "right" way to fix the cursor size problem:

The "right" fix: Wayland cursor shape protocol

The simple and reliable way to get consistent cursors across apps is to not let apps draw the cursor at all. Instead, they only specify the name of the cursor shape, and the compositor draws the cursor for them. This is how Wayland cursor shape protocol works. Apps no longer need to care about the cursor theme and size (well, they might still need the size, if they want to draw custom cursors in the same size as standard shapes), and since the compositor is the only program drawing the cursor, it's guaranteed to be consistent for all apps using the protocol.

(It's quite interesting that we seem to went a full circle back to the original server-defined cursor font way in X11.)

Support for this protocol leaves a lot to improve, though. Not all compositors support it. On the client side, both Qt and Electron have the support, but GTK doesn't.

There are merge requests for GTK and Mutter, but GNOME devs request some modifications in the Wayland protocol before merging them, and the request seems to be stuck for some months. I hope the recent Wayland "things" could move it out of this seemingly deadlock.

Anyway, with this protocol, only the compositor has to be modified to support a new way to draw cursors. This makes it much easier to change how cursors work. So we come to:

SVG cursors

Immediately after the fix in Breeze, I proposed this idea of shipping the source SVG files of the Breeze cursor theme to the end user, and re-generate the XCursor files whenever the user changes the cursor size or global scale. This way, the theme will always be able to provide the exact size requested by apps. (Similar to the "modify XCursor lib" idea, but in a different way.) It would remove the limitation 2 above (and also limitation 1 if 3rd-party themes ship their source SVGs too).

With SVG cursors support in KWin and Breeze, I plan to implement this idea. It would also allow the user to set arbitrary cursor size, instead of limited to a predefined list.

Problems you might still encounter today

Huge cursors in GTK4 apps

It's a new problem in GTK 4.16. If you use the Breeze cursor theme and a large global scale like 2x or 3x, you get huge cursors:

It has not limited to Plasma. Using Breeze in GNOME would result in the same problem. To explain it, let me first introduce the concept of "nominal size" and "image size" in XCursor.

Here is GNOME's default cursor theme, Adwaita:

"Nominal size" is the "cursor size" we are talking about above. It makes the list of sizes you choose from in the cursor theme settings UI. It's also the size you set in XCURSOR_SIZE. "Image size" is the actual size of the cursor image. "Hot spot" is the point in the image where the cursor is pointing at.

Things are a bit different in the Plasma default cursor theme, Breeze:

Unlike Adwaita, the image size is larger than the nominal size. That, combined with a global scale, triggers the bug in GTK4. Explanation of the bug.

XCursor allows the image size to be different from the nominal size. I don't know why it was designed this way, but my guess is so you can crop the empty part of the image. This both reduces file size, and reduces flicking when the cursor changes (with software cursors under X11). But the image size can also be larger than the nominal size, and Breeze (and a lot of other themes) uses this feature.

You can see in the above images that the "arrow" of nominal size 24 in Breeze is actually similar in size to the same nominal size in Adwaita. But the "badge" in Breeze is further apart, so it can't fit into a 24x24 image. That's why Breeze is built this way. In a sense, "nominal size" is similar to how "font size" works, where it resembles the "main part" of a character in the font, but some characters can have "extra parts" that go through the ceiling or floor.

This problem is already fixed in the main branch of GTK 4, but it's not backported to 4.16 yet, probably because the fix uses a Wayland feature that Mutter doesn't support yet. So at the moment, your only option is to use a different cursor theme whose "nominal size" and "image size" are equal.

Smaller cursors in GTK3 apps (most notably, Firefox)

The cursor code in GTK3 is different from GTK4, with its own limitations. You might find the cursor to be smaller than in other apps, and if you run the app in a terminal, you might see warnings like:

cursor image size (64x64) not an integer multiple of scale (3)

GTK3 doesn't support fractional scales in cursors. So if you have cursor size 24 and global scale 2.5x or 3x, it will use a scale 3x and try to load a cursor with a nominal size 24x3=72. And it requires the image size to be an integer multiple of the scale. So if your theme doesn't have a size 72, or it does but the image size is not multiple of 3, GTK3 fallbacks to a smaller unscaled cursor.

End words

OK, this is a long post. Hope I can bring you more cursor goodies in Plasma 6.3 and beyond.

A few thoughts on Plasma/Wayland, KWinFT

Eike Hein — Mon, 19 Oct 2020 00:00:00 +0000

There's a lot of intense, opinionated debate on the current state of Plasma's Wayland session these days. This seems to be fueled by mainly two events, Fedora's announcement to flip to Wayland by default for version 34 of their KDE variant, and a a recent fork of KWin and a few other components of Plasma, KWinFT.

On the first, I think it's a great move. Concerns of a repeat of the "shipped before it's ready" situation of early KDE 4 releases aside (for now; more on this in a moment), it certainly feels like it makes sense for Fedora in particular - it's a bold, technology-focused early adopter move, something I think the Fedora user audience generally appreciates the distro for. Plus other Fedora variants default to Wayland already, so there's an appreciable desire to make the various offerings more consistent.

Distros should understand the user audiences they're trying to cater to, and if a distro believes there's a market for a particular flavor of desktop, it's certainly fine to challenge upstreams to provide the needed software. I think as far as Plasma on Wayland is concerned, the challenge is thoughtfully timed - it's coming after the KDE community voted to declare good Wayland support a community-wide goal, after all. I think there's every reason to believe this decision will lead to good things if the two (and overlapping) communities collaborate to make a good showing. Nice.

It's 2020, for crying out loud! Why is this taking so long?

A lot of us have some things in common. For example, if you're reading this, chances are you are the sort of person who is not indifferent to technological progress, even easily excited by it. Many of us also are also drawn to competition.

So people really care about how far down the road to Wayland adoption every of the competing projects is, and theories abound on what the comparison says about them. This is set against a backdrop of Wayland also still maturing as an upstream technology, driven forward by the same competing projects working together.

One particular claim that's been popping into the conversation lately is that Plasma not having the Wayland conversion safely in it's rear-view mirror yet is evidence of a project that's somehow fundamentally flawed, and unable to focus on what matters and make good long-term plans and roadmaps. If you didn't encounter this in one of the heated debates on social media yet it probably sounds a bit breathless to you, or maybe not really worth acknowledging - but it's actually my main reason to write this blog post, because it's an interesting excuse to talk about recent Plasma history!

Plasma 5.0 was the second large-scale rewrite of KDE's desktop environment offering in a row, meaning both 4.0 and 5.0 had debuted with a lot of new and young lines of code inside them. Both rewrites were motivated by lifting the desktop shell to a newer set of its base technologies - for example major versions of Qt, OpenGL-based UI rendering and so on. Younger code tends to have higher defect rates. At the time, the standard criticisms in online discussions about Plasma went something like this:

"It looks great, but it's really buggy" "I like a lot of the features, but it's missing those last 5% to fit my needs fully" "It's resource-heavy and doesn't perform smoothly enough on my machine"

And a less concrete one, but nearly as often repeated:

"It's really coming together now, but I'm already worried about the next major version being another rewrite and making it shaky"

The Plasma project paid attention, and made a number of very strategic decisions to set its focus on a set of goals:

Improve quality across the board by prioritizing bugs and bringing defect rates down
Go the distance with features, drive them to completion and make them easier and more consistent to use
Lower the resource needs and scale down to much lower-powered hardware, including ARM SBCs
If we do additional rewrites of fundamental code (and we ended up replacing major pieces in 5.x point releases, e.g. the entire taskbar, menu and notification systems - each of those quietly addressed dozens of bugs, but went mostly noticed for a few new features), there needs to be a noticeably positive impact on the above metrics

This remains the spirit of the Plasma project today, with many activities spanning multiple quarters of a year of work at the service of those goals. Recent examples include the Breeze visual refresh undertaken by the Visual Design Group, the revamp of session init with optional use of systemd, and the new cgroups-loving way of running apps.

For Plasma on Wayland, this meant: While we strongly believing in the tech, we would take our time to get it right, and not declare the offering ready before it isn't up to par. It also wasn't always the highest-priority development activity going on, with many other steps being simultaneously taken to reach our goals. Reasonable people can (and do) have diverging opinions on the relative prioritization of work, of course, but the path we walked was most definitely a consciously strategic one - one that has lead to the gradual disappearance of those earlier quotes from user feedback we receive, speaking to its execution. Work continues!

KwinFT

One source of these concerns is the KWinFT project, a recent fork of the compositor service in a Plasma system along with a few choice pieces of support code (e.g. the screen config subsystem).

KWinFT is a project by Roman Gilg, a contributor to KWin and KDE in general. Roman will not be shocked by reading this, as we had this discussion a couple of months before he announced the project, as well as recently, but I don't think the fork was necessary, or is a very good idea overall. I think his technical ideas for KWin are interesting, and think there were better options to deliver their value to users and have a bigger impact in the end, e.g. by making more aggressive use of feature/staging branches to prove out subsystem rewrites before merging them up. This is a suggestion I made at the time, too, and I haven't seen anything to change my mind since. We certainly keep talking.

This is a very personal opinion and speaks to my own style to open source involvement more than anything, which is shaped by the vibe of the KDE community and the KDE mentors and role models I received my education from. I believe in prioritizing user value, and in leadership by aligning diverse talents towards common goals, by being inviting, communicative and persuasive. I really don't believe these options were fully exhausted in this matter, and while I understand that starting a new project can make it easier to try out e.g. some different organizational ideas (and my impression of the fork is that it's really more about those than any actual tech disagreements) without having to do the work of getting others on board, I don't think this ultimately succeeds in bringing improvements to the max number of people who might benefit from them.

On the tech side, though, it's important to keep the focus of the conversation on Plasma on Wayland as a whole. KWin is an important component of that system, but owing to its multi-process architecture, it's only one of a fairly large and varied set of codebases that need to complete their porting efforts. Many use cases additionally require coordinated activity across several components (for example: the taskbar, System Settings, ...), and it's also still not too difficult to identify needed upstream improvements in Wayland to get over the finish line, some of which the Plasma team is currently driving forward.

And no, this isn't stacking features on shaky foundations - most of this work is technically orthogonal (easy to see for the ones that aren't in the same codebase or even project!), and in any case, the more pleasant Plasma's Wayland session becomes to consume, the higher the set of potential contributors exposed to the remaining tasks. Those attention dynamics of open source are fairly reliable :-). In any case, this is perhaps actually my main beef with the technical criticisms coming from the debates surrounding KWinFT - they are myopically focused on KWin and derive from this grander projections, ignoring the full picture of the system and a lot of other heavy-hitting technical activity all throughout it (including some of the projects linked throughout this post). The resulting signal-to-noise ratio is not very engaging overall. KWin != Plasma is an important constraint to add to them.

Linux desktop shell IPC: Wayland vs. D-Bus, and the lack of agreement on when to use them

Eike Hein — Sun, 11 Oct 2020 00:00:00 +0000

On the Linux desktop today, we have two dominant IPC technologies in use between applications and the desktop environment: Wayland and D-Bus. While created for different reasons, both are generically extensible and can be used to exchange data, synchronize state and send requests and signals between peers. A large number of desktop use cases are implemented using either technology, and some use cases are already distributed across both of them. The status quo is mostly the result of organic growth, with individual implementation choices down to tech friction or the lack thereof.

For some use cases the choice of which to use is not obvious. This is one of the factors still slowing down the standardization and hence adoption of Wayland-based sessions currently.

The overlap

While the semantics of Wayland and D-Bus are really pretty different, both enable the exchange of structured, typed data between peers along with RPC-shaped uses. While D-Bus supports many more connection topologies than just one process talking to another, for applications interacting with the desktop environment via protocols both parties agree on the difference is small and usually hidden by toolkit abstractions.

More importantly, both technologies were created to service the same key users - desktop environments and application toolkits - and widely adopted protocols layered over both transports deal in some of the same primitives coming from that ecosystem. For example, .desktop file names as stable application ids are referenced in both the Wayland xdg-shell protocol as well as well as <a href="https://www.freedesktop.org/wiki/>freedesktop.org's <a href-"https://specifications.freedesktop.org/notification-spec/latest/>notifications protocol.

The current usage split between the two protocols is a result of tech friction and little planning - some things are easier to talk about on a Wayland connection, others are easier to talk about on the D-Bus. It's down to the protocols we already have in hand now, adoption in various codebases and a spectrum of opinions.

Tech friction

Wayland (cool book link this time!) is the designated successor to the venerable X windowing system. Born from the same community, it's certainly informed by some of X's successes, but also many of the pain points experienced by implementers of X over the years. A lot of the advances in Wayland relate to the particular problems of windowing and presentation, but its heritage also did much to set the scene for revisiting what really belongs into the core windowing system and what doesn't. D-Bus and even its own direct predecessors did not exist for much of X's long and storied history. Conversely, in the Wayland world it has become a lot harder (in terms of scrutiny applied by the community) to get a desktop feature into a widely-adopted spec than it was in X, which for a long time was the only widely adopted transport medium in place.

D-Bus is a far more generic IPC/RPC technology supporting a wider variety of connection patterns between parties. Service activation through the bus, multicast signals open to any participant, pervasive introspection of interfaces - you won't find much of this in Wayland, and D-Bus is the latest in a chain of technologies driven by genuine needs for such capabilities.

There's a third element to the discussion, and it's the rise of the freedesktop.org standards ecosystem, broadly promoting interoperability between desktop environments and the portability of apps between them. Put on a timeline, freedesktop.org and D-Bus happened a decent number of years prior to the arrival of Wayland - D-Bus, therefore, has a headstart in being the medium of choice for freedesktop.org specs and fd.o standards being referenced in protocol and service designs.

In the end:

Wayland is the natural transport between the application and the compositor, one of the key services of the desktop environment. Windowing being the goal, a lot of the protocols in place now make it easy for the two parties to converse at the level of windows. In xdg-shell, the application can also let the compositor know its application id as part of window metadata. This is one of several established ways for the compositor to know what application it's talking to. (A more recent aid is mapping from the client to a cgroup set up by the application launcher, e.g. Flatpak or Plasma, which can improve the security of this type of authentication. In both Wayland and D-Bus, you sometimes see this need - and much more - addressed by inserting a protocol proxy like xdg-dbus-proxy or Sommelier, respectively.)
D-Bus is the transport used for many other app-to-service interactions, e.g. notifications. On D-Bus it's often convenient to find the application id of a participant, but it's hard to relate the conversation to the windowing system. For example, efforts to relate a D-Bus notification event to a particular window to jump to are fairly recent and not yet widely implemented.

The decision vacuum

There's a particular snag in the timeline: With D-Bus arriving on the scene a lot later than X, a lot of interactions between apps and the desktop environment were spec'd into the X medium in the past. For example, various forms of window or broadly application state (e.g. requesting user attention) or requesting focus/activation from the window manager. No one thought to put onto D-Bus what was widely adopted and working already, although sometimes more comprehensive replacements gravitated towards using D-Bus instead and managed to get traction.

With X being replaced, a lot of the stuff in ICCCM and EWMH/NetWM is now up for grabs for either Wayland- or D-Bus-based specs.

Current trends: Plasma vs. Gnome vs. wlroots/Sway

Wayland is the natural choice for a compositor service to talk to apps. D-Bus is the most popular option for other desktop environment services to talk to apps. In some desktop environments, the compositor and other services may live in the same process (Gnome Shell in particular), others distribute services over few or many processes.

In Plasma, the compositor and the desktop shell are two seperate processes. The compositor implements the window management policy, and the desktop shell process draws your wallpaper, your panels and your menus. The notifications service lives in the Plasma desktop shell process as well. This architecture is a straight port-over from the X way of doing things, but it remains advantageous - for example, a crash in the shell won't bring your compositor (and then your apps) down with it. In fact, we're aiming for still more process isolation in future generations of Plasma.

The compositor and the shell being in different processes requires them to synchronize state. The shell also needs to pose requests to the compositor. In Plasma, this communication happens through a set of Plasma-specific Wayland protocols. This is a good example of a friction-driven implementation choice: As the shell and the compositor want to mainly converse about windows, using Wayland posed the least friction. On the other hand, in cases of the compositor talking to support processes such as the screen configuration service or the System Settings app, the choice of transport varies - Wayland protocols in some cases, D-Bus interfaces for others (notably virtual desktops configuration). Overall, we don't have a clear IPC usage policy at the moment.

For other desktop environments I cannot speak with any true authority, especially make no claims about implementation policy. Perhaps owing to the single-process shell architecture, I see our friends at Gnome using D-Bus-based protocols in a few places where we use Wayland-based ones, e.g. for screen configuration (edit: lack of friction between D-Bus and XDG desktop portals has been pointed out to me as another factor; makes sense).

The wlroots community (consisting of Sway and lots of other users) seems to broadly prefer Wayland over D-Bus to run protocols through. It's easy to surmise why - wlroots' raison d'être is to enable building shells on top of Wayland, and in particular shells built up of interoperating pieces made by distinct authors. Enabling this interoperability through the community's Wayland-based tooling must come naturally, and the wlroots community is no doubt leading this particular effort at the moment. Some of these protocols are great, and it's likely Plasma will implement more of them in the future.

Unresolved cases

An example where the lack of a clear choice has been slowing the desktop community down is focus/activation requests. Consider the following common usage pattern: The user clicks a link in a chat app. It opens in the default browser. For convenience, the user might want the browser window to be raised to the front now, the click being an instruction to the system to form a smooth workflow from one app to the other.

It might come as a surprise, but 12 years in, there's no good, widely-adopted solution to making this work in Wayland-based desktops.

It should not come as a surprise, however, that this an example handled in the past by an X-based protocol that's now out of the picture. The X way of doing things wasn't very robust - it put a lot of trust into the application posting a legitimate request to be activated, and it required the window manager to implement complicated heuristics to filter out illegitimate or just ill-timed requests. These heuristics are collectively known as "focus stealing prevention", e.g. sticking to the current window while the user is typing into it. For now, Wayland-based desktops by and large are skating by on even poorer semantics - giving focus to any new window while relying on heuristics, with partial solutions to the problem of already-existing windows not pervasively implemented across apps.

It's a good example of a case where the community really doesn't want to miss a chance to get it right this time. While trying to do so, a lot of more or less related desktop features have been looked at as well - for example, the X convention of apps placing attention hints on their windows to blink them in the taskbar, to be cancelled by the window manager when the window is raised and focused. Also the case of applications posting notification events through D-Bus carrying a link back to particular window, e.g. to jump from a chat message alert bubble to the specific conversation window.

Over the last couple of years, many different approaches have been proposed and tried, and we still don't have the One True Spec.

There seems to be fairly solid agreement on the need for a token exchange mechanism to clear the focus handover in the compositor - the chat app requests a token from the compositor, hands it to the browser handling the link (e.g. through an environment variable) and the browser may use it to request focus from the compositor. But there remains a lot of division over whether the activation request (along with other use cases) should be layered over the D-Bus-based notification spec, or whether all of this should remain solidly Wayland territory:

The argument for D-Bus is that a mechanism to relate notification events to particular windows (by including a window handle in the metadata) is needed anyway, and once that's in place, it's easy to add in the focus token. Using special notification events to inform about window-specific ongoings is an extensible pattern potentially spanning all of activation and attention-seeking, along with things like taskbar job progress meters and others. The event spec also already has fields useful for accessibility - imagine a system where a blind user gets a "app X wants attention for Y" readout, without needing to craft a new protocol to tell the compositor specifics about Y. On the other hand, going this route clearly also requires some spec work for existing notification service implementations to be able to do the right thing when processing these special events.
The argument for Wayland is that the above requires a lot of translation forth and back (or rather, import and export of handles and tokens), and in the case of multi-process service architectures, expensive chaining of IPC. Plus it requires a Wayland-based desktop environment to use D-Bus for a core use case, while an X11-based desktop environment could do without a second transport for the same features. For some projects, this is an unattractive expansion of their current dependencies.

In conclusion

I suspect the above example of focus/activation requests will ultimately be addressed by a token exchange via Wayland, and the notification spec way of doing things will be implemented alongside it as well, rather than picking one way of doing things. And perhaps that's fine.

But it's worth stopping for a moment and being conscious of what's going on. We would all benefit from some commonly agreed-upon guidelines on where the scopes of Wayland and D-Bus end in our application platform, and where they overlap. Where does the windowing system start and end? Where should new protocols go? We also want to be smart in spec'ing out how the two mediums relate to each other, and making translations from one of the other safe and robust.

In addition to our regular comm tools of forges and merge requests, a natural venue for these kinds of discussions is the Linux App Summit, an event co-hosted by KDE and Gnome. LAS 2020 is just one month away. Perhaps it's a good chance for a sit-down about these things.