Hacker News Reader

Comment by cycloptic | Hacker News Reader

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

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.

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.

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.

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.

> 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.

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?

>I'm very confused, if you don't need a visual user interface, why bother with a windowing system?

Hi, so let me tell you an example I use, just so you have a broader perspective of how some people use their desktop.

I have eye problems so it is hard for me to read text, so I use different built in tools but I also create my own scripts combining CLI tools using bash or python.

One such script I use to have dialog from different text heavy games read to me, if the game/engine is open I can patch it to read the text directly but if is proprietary I use this following script

1 grab a screenshot of a section of the screen use a CLI program, I do not want a visual tool to be shown when I run it

2 using same CLI tools I apply transformations to the images, like grayscale and other stuff

3 I OCR the screen, image to text

4 I have the text read to me

My script uses cross platform CLI tools, it would work the same in all Linuxes, Windows and maybe OSX (did not check if all those CLI ones work on Mac but I think they work)

It would suck if I would not be able to use this CLI tools n future and have to make a GNOME/KDE or other DE extension 2 run some other transformation

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.

I don't need any contact with Microsoft to tell you they regret making that possible under windows. It is a security escalation just waiting to happen. Yes those scripts done well are useful, but the abuses are bad.

I'm sure Microsoft wants to rewrite their api. There are a lot of issues with it that are obvious with only a little knowledge. Those who know their api better than me can probably propose a better replacement than I can. However a replacement is tricky as Wayland shows, so I can't blame them for not going forward with it (at least not so far )

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.

The functionality is there by hacking the compositor in unstable ways that might break on the next update and only work for a single compositor. — the only thing that makes this different from editing the source of the compositor is avoiding the recompilation step.

Surely we can agree that being forced to hack the internals of the compositor by way of an unstable a.p.i. is a less than satisfactory solution compared to X11's stable, universal a.p.i.'s that work everywhere?

I can't agree because the alternative would be exposing those unstable private APIs over the Wayland protocol, which would probably not please you either. Some of those X11 APIs are not actually stable and don't actually work everywhere too, they require special support from the window manager.

The issue is that the a.p.i. is not stable and not standardized.

On X11, what I described can be done in a stable, standardized way; on Wayland, it requires hacking the compositor's internals in semi-supported, unstable ways.

These are the differences in features whereof I spoke that make Wayland and unrealistic platform for many users in it's current state.

But the thing is it's not really standardized or stable in X11 either, most client-to-client communications are done through various window properties which are not technically part of the protocol and support for them varies between window managers. If your window manager doesn't support it then it's the same, you have to hack the window manager's internals. Honestly, whatever advanced feature it is that you want would be much better achieved by creating a kwin script or gnome extension and then going from there, I believe there is work underway to stabilize some APIs for both of those but as with X window managers, there is a lot of functionality there and there is no guarantee they will stabilize exactly what it is that what you want.

Do you know a single modern window manager of note that does not support E.W.M.H.?

The “if” on X11 at this stage is a theoretical obscurity with every modern window manager of note supporting it, with the user being confident that it shall remain stable; on Wayland, the reality is that every single compositor has it's own own, typically unstable ways of doing this, though Sway is the one that is committed to stabilizing it and wants it's way of doing these things to become a standard, but that is of little use when the others are not picking it up.

Plenty of older window managers don't support it correctly or use non-standard properties. Plenty of newer window managers have non-standard internal properties for unstable features too.

I would not say that Sway is doing anything special here, what they have done is exactly what I was saying earlier: placed the unstable private APIs in the Wayland protocol, with all the problems that entails. Applications should probably not be consuming those APIs directly, they will likely want to go through an abstraction layer.

Reply on news.ycombinator.com