5 ms·

I think that's why TFA is working on some of the features that are missing, e.g. a native Wine port.

Blikkentrekker 6y ago
Those are not the features of the protocol that are missing; that is an application that does not support it. The features of the protocol that are missing are what made Wine developers indefinitely shelf their attempt to port it and as I read it, this port indeed is only a partial port for certain use cases that can't map the entirety of Window's windowing a.p.i. as Wine generally can. The reason many people aren't using Wayland is not because their favorite application does not support it yet, but because at this stage the protocol on a fundamental level does not allow them to do what they need to.
- cycloptic 6y ago
  In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works. Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.
  - makomk 6y ago
    Wayland is kind of unique in that it is deliberately, intentionally impossible to run applications written for any other window system on top of it. All the others are pretty well cross-compatible - Win32 applications can run on X11 and vice-versa with an appropriate compatibility shim, both can run on OS X just fine too, and in theory OS X apps could probably run on other platforms if anyone cared to develop the code to do it, but none of them can run under Wayland. By design. The only reason XWayland works is because every Wayland compositor currently bypasses the limited Wayland APIs and implements a large chunk of X-specific code to enable it, and if they ever get tired of maintaining that say goodbye to compatibility with any existing pre-Wayland GUI applications regardless of original platform.
    - cycloptic 6y ago
      A solution there would just be to add a similar large chunk of Wine-specific code, which could be an option now if none of the other options work. There is no real other way to do it if the other window systems are going to break the security assumptions in Wayland. Edit: AFAIK the only real reason X11 needs special support is because functionality that would normally be provided by an X window manager needs to be provided by the Wayland compositor, most of the heavy lifting translating the X11 protocol is done out-of-process in XWayland. The amount of code needed there on the Wayland server side is actually not particularly large, I don't know enough about all usages of the Win32 API to say how that compares.
  - Blikkentrekker 6y ago
    > In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works. I feel this is the misunderstandng. You're reasoning from a perspective of “applications”. Most users who are unsatisfied with Wayland's capabilities are reasoning from a perspective of “utilities” and “functionality”. Wayland indeed repræsents a move towards the “everything is an app” philosophy. The functionality that is left behind that is needed for the workflow of many are the programs that are not applications and in no way manifest a visual user interface but nevertheless are required for many users.
    - cycloptic 6y ago
      I'm very confused, if you don't need a visual user interface, why bother with a windowing system? Isn't the point of that to have visual user interfaces? What functionality is missing?
      - Blikkentrekker 6y ago
        Because on X11 I can rul tools to trace and debug the windowing system as it is running, introspect it's state and make changes to it. For instance, I run a variety of scripts that automate the placement of windows as I desire it based on hotkeys. These scripts do not have any window of their own; they simply manipulate the placement of other windows or otherwise query their status to do this. — this is not generally possible on Wayland at this moment. Such programs are also possible under Windows and are utilized by many users to enhance the functionality of their windowing system.
        cycloptic 6y ago
        That is very possible. Under GNOME and KDE, you would do that with a gnome-shell extension or a kwin script respectively. Those both give you access to the display server's internal APIs. (potentially more than what the X11 server would give you too) Yes it's in another API and technically not in the Wayland protocol but the functionality is there. It wouldn't make sense to expose all private state of the display server over the Wayland protocol.

Those are not the features of the protocol that are missing; that is an application that does not support it. The features of the protocol that are missing are what made Wine developers indefinitely shelf their attempt to port it and as I read it, this port indeed is only a partial port for certain use cases that can't map the entirety of Window's windowing a.p.i. as Wine generally can. The reason many people aren't using Wayland is not because their favorite application does not support it yet, but because at this stage the protocol on a fundamental level does not allow them to do what they need to.

cycloptic 6y ago
In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works. Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.
- makomk 6y ago
  Wayland is kind of unique in that it is deliberately, intentionally impossible to run applications written for any other window system on top of it. All the others are pretty well cross-compatible - Win32 applications can run on X11 and vice-versa with an appropriate compatibility shim, both can run on OS X just fine too, and in theory OS X apps could probably run on other platforms if anyone cared to develop the code to do it, but none of them can run under Wayland. By design. The only reason XWayland works is because every Wayland compositor currently bypasses the limited Wayland APIs and implements a large chunk of X-specific code to enable it, and if they ever get tired of maintaining that say goodbye to compatibility with any existing pre-Wayland GUI applications regardless of original platform.
  - cycloptic 6y ago
    A solution there would just be to add a similar large chunk of Wine-specific code, which could be an option now if none of the other options work. There is no real other way to do it if the other window systems are going to break the security assumptions in Wayland. Edit: AFAIK the only real reason X11 needs special support is because functionality that would normally be provided by an X window manager needs to be provided by the Wayland compositor, most of the heavy lifting translating the X11 protocol is done out-of-process in XWayland. The amount of code needed there on the Wayland server side is actually not particularly large, I don't know enough about all usages of the Win32 API to say how that compares.
- Blikkentrekker 6y ago
  > In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works. I feel this is the misunderstandng. You're reasoning from a perspective of “applications”. Most users who are unsatisfied with Wayland's capabilities are reasoning from a perspective of “utilities” and “functionality”. Wayland indeed repræsents a move towards the “everything is an app” philosophy. The functionality that is left behind that is needed for the workflow of many are the programs that are not applications and in no way manifest a visual user interface but nevertheless are required for many users.
  - cycloptic 6y ago
    I'm very confused, if you don't need a visual user interface, why bother with a windowing system? Isn't the point of that to have visual user interfaces? What functionality is missing?
    - Blikkentrekker 6y ago
      Because on X11 I can rul tools to trace and debug the windowing system as it is running, introspect it's state and make changes to it. For instance, I run a variety of scripts that automate the placement of windows as I desire it based on hotkeys. These scripts do not have any window of their own; they simply manipulate the placement of other windows or otherwise query their status to do this. — this is not generally possible on Wayland at this moment. Such programs are also possible under Windows and are utilized by many users to enhance the functionality of their windowing system.
      - cycloptic 6y ago
        That is very possible. Under GNOME and KDE, you would do that with a gnome-shell extension or a kwin script respectively. Those both give you access to the display server's internal APIs. (potentially more than what the X11 server would give you too) Yes it's in another API and technically not in the Wayland protocol but the functionality is there. It wouldn't make sense to expose all private state of the display server over the Wayland protocol.