Introduction

[outfoxxed]

In this repo I've attempted to create some generic wayland protocols that make common functionality expected/desired in desktop shells available to clients. The intention is to upstream most of these to w-p at some point but I'm hoping to get implementations earlier so we can actually use them, though I'm open to trying to upstream them now instead of keeping them here.

Before starting any implementations I'd like to ask for input on my current drafts if you're interested:
#1 - wlr/ext toplevel association
#2 - foreign toplevel icons
#3 - surface intersection observer / window dodging
#4 - non popup seat grab
#5 - ext-workspace toplevel management
#6 - ext-workspace creation / making ext-workspace usable for dynamic workspaces
#7 - toplevel geometry

Pings: @vaxerski @YaLTeR @Aylur @JakeStanger @vnuxa
Potential interest: @ifreund @johanmalm @ammen99 @Alexays @its-darsh

Apologies for the ping if uninterested.

[its-darsh]

Interested enough. how can I help?

[outfoxxed]

Just look over the protocols and point out anything you think is bad, missing, too much etc. I'll be writing implementations for Hyprland and Quickshell personally, though the workspace stuff requires an ext-workspace implementation first.

[its-darsh]

Just look over the protocols and point out anything you think is bad, missing, too much etc. I'll be writing implementations for Hyprland and Quickshell personally, though the workspace stuff requires an ext-workspace implementation first.

Great. Will start doing so once I get down on my desk...

[vaxerski]

I have been summoned

[tmccombs]

Given that several compositors (sway, hyprland, and niri for example) already have much of this functionality exposed over a json based message protocol over a unix domain socket, I wonder if it would make sense to create a standard for a subset of that ipc that is compatible across multiple compositors, rather than creating new Wayland protocols.

[vaxerski]

JSON has many, maaany disadvantages, some include:

• slower
• way less rigid: prone to compositor-led hacks and addons
• just look at what dbus has become

[its-darsh]

Not super sure about the DBus thing. However, a yet another protocol(s) is not the fix for all of clients' issues, of course, unless standardized, otherwise what's going to make it different than IPC?

[vaxerski]

well the idea would be to get us together and agree to take this as a place to make things standard

[tmccombs]

I just suggested json because it:

• is already used by multiple compositors (and x window managers)
• is widely supported across many programming languages, and many clients will likely already have access to a decent quality implementation

That said I'm not necessarily opposed to using something else, although there are tradeoffs with any choice. And I would urge not to invent an entirely new format for this.

just look at what dbus has become

I'm not sure what you are referring to, and dbus doesn't have anything to do with json.

I actually considered suggesting using dbus instead, but from what I've seen that would probably not get much traction with sway at least.

Advantages I see of using a different IPC mechansim instead of wayland protocols.

Could be json messages, or dbus, or msgpack/cbor, or whatever. For now I'm just focusing on wayland protocol vs something else.

• if a compositor doesn't have an implementation of this protocol natively, either because the maintainer isn't interested, or the user is using an older version of the compositor, it may be possible to create an adapter proxy that converts between this new standard and the compositors native ipc.
• it is easier to block access to sandboxed apps (flatpak, snap, etc.). Maybe someday we'll have some kind of access control or privileges for wayland protocols, but we aren't there yet.
• the protocol could potentially not be wayland specific, and could thus be implemented on other environments as well

Disadvantages I see

• it adds another protocol compositors need to implement, especially if the compositor doesn't already have an existing ipc that is potentially compatible with the new standard
• there could be bikeshedding over what format to use, that leads to delaying standardization
• some functionality may require wayland protocols anyway, so the new protocol may only be applicable to a subset of the desired functionality
• the possibility for an adapter may reduce motivation for compositors to natively support the protocols

[outfoxxed]

In my opinion, using any transport other than wayland makes this a much bigger mess for a few simple reasons:

• Protocol objects: The additional protocols here are meant to be used with existing standard protocols. I do not want to re-create the entire protocol surface over json, and even if we did, we'd need another protocol simply for matching wayland and json objects to eachother. This is all much more work for everyone involved.
• Synchronization: Using wayland protocols means the events exposed here can be perfectly synchronized to ones already in wayland, and obey existing conventions. Dealing with N different IPC protocols that are all synchronized slightly differently (or worse not at all) and refer to the same objects is awful.
• Eventual standardization: My hope is that some of these will end up standardized in some form, and not many changes will be required on the compositor or application side when that happens, which would not be true of a non wayland-based protocol

it is easier to block access to sandboxed apps (flatpak, snap, etc.). Maybe someday we'll have some kind of access control or privileges for wayland protocols, but we aren't there yet.

The security context protocol exists to strip privileged protocols from unprivileged clients like flatpak. Most protocols here would be filtered by it.

just look at what dbus has become

I'm not sure what you are referring to, and dbus doesn't have anything to do with json.

DBus protocols implemented by more than one application are a mess and the bus itself does not promote or enforce consistency in any way. Json-based protocols would likely have a similar issue.

As for sway I wouldn't really expect them to support dbus, json, wayland, or any other type of extra protocol i3 doesn't.