14 ms·

That is a single Wine staging developer, however., not “wine developers”. That having been said, I share some of the concerns that Wayland is pushed, not as an

That is a single Wine staging developer, however., not “wine developers”. That having been said, I share some of the concerns that Wayland is pushed, not as an alternative to X11 but as a replacement that many powerful players insist must and shall replace X11, all the while lacking many features that X11 has and that are used.

bluGill 6y ago
Wayland is pushed because nobody is maintaining X11, the people who used to maintain X11 are now working on wayland. In short your choice is push wayland everywhere, or fund a new group of people to maintain X11. For the later I have little confidence in one person alone making significant progress, but if you want to prove me wrong - well good luck. I am betting on wayland long term, though I still have X11 a lot of places.
- Blikkentrekker 6y ago
  Perhaps , but that doesn't change that as of this moment, Wayland lacks many feature that users have come to rely on. Certainly you can see the problem with the situation that developers of one project abandon it and start a new project that lacks many of the features of the old and claim that users should use the new one. It's not an issue of what will win in the long run; it's an issue of a replacement product being pushed for adoption long ere it be ready.
  - cycloptic 6y ago
    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.
  - matthewmacleod 6y ago
    *Wayland lacks many feature that users have come to rely on. Can you explain what you think these are? In my experience, this is not really the case.
    - Blikkentrekker 6y ago
      An example would be that X11 has protocols to allow the manipulation of currently selected text. In Wayland no such protocol exists as it's entirely agnostic of how clients handle input and render text. The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all. A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.
      - cycloptic 6y ago
        In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.
        stelonix 6y ago
        Fake input under X11 (XTEST) is marked as fake input and any application receiving such events can choose to ignore it. Wine does it, for example.
        cycloptic 6y ago
        Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.

bluGill 6y ago

Wayland is pushed because nobody is maintaining X11, the people who used to maintain X11 are now working on wayland. In short your choice is push wayland everywhere, or fund a new group of people to maintain X11. For the later I have little confidence in one person alone making significant progress, but if you want to prove me wrong - well good luck. I am betting on wayland long term, though I still have X11 a lot of places.

Blikkentrekker 6y ago
Perhaps , but that doesn't change that as of this moment, Wayland lacks many feature that users have come to rely on. Certainly you can see the problem with the situation that developers of one project abandon it and start a new project that lacks many of the features of the old and claim that users should use the new one. It's not an issue of what will win in the long run; it's an issue of a replacement product being pushed for adoption long ere it be ready.
- cycloptic 6y ago
  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.
- matthewmacleod 6y ago
  *Wayland lacks many feature that users have come to rely on. Can you explain what you think these are? In my experience, this is not really the case.
  - Blikkentrekker 6y ago
    An example would be that X11 has protocols to allow the manipulation of currently selected text. In Wayland no such protocol exists as it's entirely agnostic of how clients handle input and render text. The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all. A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.
    - cycloptic 6y ago
      In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.
      - stelonix 6y ago
        Fake input under X11 (XTEST) is marked as fake input and any application receiving such events can choose to ignore it. Wine does it, for example.
        cycloptic 6y ago
        Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.