RFC: new category for legacy compatibility extensions
Read this before commenting
Please do not fill this issue with a laundry list of 'I would like feature A together with behaviour B'. Specific feature requests should be raised in their own issues to be discussed there, not in this issue. Any comments raising feature requests in this issue will be snipped. Thankyou.
Introduction
Legacy compatibility is an issue, because Wayland design principles are fundamentally different from any other widely used window system API or protocol. In many cases, there cannot be a useful translation from existing application toolkit APIs to Wayland, because the toolkit APIs do not have the necessary concepts, and the applications have not been designed to use those concepts. Those concepts did not exist or were not needed, when any of them were designed. Porting an application to Wayland may require re-designing the very ways it constructs its UI. Obviously this is a problem in the sheer amount of work, let alone apps that simply won't be ported.
The first level of legacy compatibility is Xwayland. It requires zero changes to applications and toolkits, and allows most applications to just work. The key that makes Xwayland work is its required integration with the Wayland compositor: the Wayland compositor must become the X11 window manager. The Wayland compositor sees the legacy prescriptive X11 interfaces, and can do whatever is necessary to accommodate them as well as possible.
A key point of Xwayland integration is that the Wayland compositor only needs to make the application work well enough. It does not require the Wayland compositor to do exactly what the legacy applications tell it to.
The problem
Application toolkits have been ported to become native Wayland clients. This suffers from the differences in the system design principles. On one hand, applications should work. On the other hand, Wayland should not lose the very principles it is built upon - the principles that promised a better future.
A proposal
Let us define a new protocol extension category: legacy compatibility extensions
In wayland-protocols governance terms, extensions in this category would be in the ext namespace, or they should get their own namespace if people want different acceptance criteria.
In wayland-protocols phases, these extensions would be introduced and remain in the deprecated/ directory. Alternatively, they could have their own directory.
A legacy compatibility extension would be designed based on these principles:
- It closely models the piece of legacy toolkit API or (X11) protocol that toolkits need it for.
- The interface is defined in terms of how applications use it or how the legacy toolkit API or protocol works.
- The interface does not define how compositors must implement it.
Closely modeling the legacy API does not widen its usability to new areas and does not confuse old and new concepts. It makes the legacy interface recognizable to those familiar with legacy designs. Defining the interface in the legacy terms rather than Wayland terms documents what is expected of the interface. It is for legacy compatibility, and should be avoided if possible.
Not defining how compositors must implement a legacy compatibility interface is key. This allows compositor implementations to choose the most appropriate implementation to them, without needing to compromise their own designs. This is similar to Xwayland integration. If compositor behavior looks broken to someone, they can report a bug against the compositor implementation, and the developers of the compositor project will evaluate the report. Protocol specification cannot be used as leverage to coerce compositors into specific behavior.
This makes legacy compatibility extensions roughly follow the Wayland design principles: clients describe what they have, and compositors handle that the best possible way they can. The protocol is descriptive, not prescriptive.
This also makes the legacy compatibility extensions inherently unreliable, which also makes them unattractive. This is a positive trait, because the use of legacy compatibility extensions should reduce over the decades, making them even more unreliable, improving the adoption of the Wayland application design principles: describe what an application has, do not tell what to do with it.
Example 1
Toolkit APIs and X11 have a way to position X11 windows in absolute coordinates. Sometimes they also provide window relationships, e.g. a window is a child for another window. Sometimes the toolkit is unaware of such relationships, even when they may exist in the application. Therefore a toolkit cannot always translate a set_position(x, y) to any higher level concept that would be appropriate for Wayland.
A legacy compatibility interface could offer a set_position(x, y) request. This would give the Wayland compositor more clues on what a legacy application is trying to do. The compositor may not literally put the window at (x, y), but it could record what the application set in order to infer what might have been the intent when another window gets a set_position(x, y) request. The compositor could also put the window at (x, y) if it suits, e.g. the window does not go off-screen and such a global coordinate system exists in the compositor. A protocol compliant compositor could also ignore all set_position(x, y) requests.