X.Org Could Use More Help Improving & Addressing Its Security

[mppix]

This

Providing the protocol that only handled a subset of features without a real implementation of it that can be integrated into currently DE's is what the biggest mistake was.

You keep repeating yourself. However, we established that wlroots is available now for everybodies use.
You are also saying that history is irrelevant but you only apply this paradigm (that for the record most would not agree with) to Xorg and use the opposite for anything Wayland.

[oiaohm]

Providing the protocol that only handled a subset of features without a real implementation of it that can be integrated into currently DE's is what the biggest mistake was.

The problem here is the amount of parts of X11 that are just screwed. There was over a decade of attempts to update X11 core to avoid the wayland change that was going to be disruption because of the requirement to go back to the drawing board in so many places.

https://criu.org/X_applications

Check point and restore functionality. X11 server protocol this does not work and cannot really be made work. KDE developers with wayland are in fact on the route to implement all the parts so check point and restore functionality can work. Yes this part of KDE developers process to support restarting the wayland compositor without restarting the wayland applications. This is not like X11 restart the DE/Compositor and leave the X11 server running this is serous-ally like restarting the X11 server and none of your applications go away in the process.

Yes part of the wayland process has been working out how to truly split applications and the output controlling compositor/server. That process has been laying the foundations to fix the check point and restore functionality.

Next part would be true multi head support. That a while out but the KDE developers are currently working on it. This is where you can run a wayland compositor per monitor connected and also transfer applications between those compositors. This would provide higher crash resistance.

Wayland is head in a direction way different to X11. X11 you start one X11 server that controls all your monitors as one big unified item. Wayland the client application is not to know about the monitors in the early design this is no mistake. This is part of the long term to check point and restore and multi head support. Think about it if the client can ask the server about all connected monitors how do you do proper isolation in multi head support and transfer applications between compositors.

Wayland goals from the start to fix all the known design issues of X11 this include the check point and restore problems is a huge mountain of work. This work would require lots of alterations in DE implementations. Complete real implementation off the start line was just not possible. Doing a change of this scale without at least some issues is also not possible.

[sinepgib]

I think that an error of the Wayland developers did was to not provide an "equivalent" of X11. From one side they choice to implement a subset of the X11 functionality (the drawing), without supporting input and all other protocol which implement the application interchange of information (like d&d, even if now the things are better). On the other side they coalesced the graphic server with the window manager.

I think the error wasn't not providing an equivalent of X11, but not providing all the pieces for it.
What I mean is, there are good reasons not to put everything into the same protocol, namely that you can never drop them, which is the issue X.org has now.
However, that doesn't mean when you create a replacement you can just say "I won't provide this" and expect people to hop on board.
For this mess to be avoided, they should have at least put as part of the commitment to build other protocols for this stuff in a standardized way.

Regarding the focus follow mouse I'm not sure what that has to do with CSD (I do for the raise on click), since the window will receive the event of focus and it doesn't need to know why it did.

[sinepgib]

RDP has always been a vector protocol ( [MS-RDPEGDI]: Remote Desktop Protocol: Graphics Device Interface (GDI) Acceleration Extensions ) and I remember I could use it just fine over a 56Kbit/sec modem connection, something `ssh -X -C` struggled with.

In fact not only it's vector based, it applies the same to video/audio/3D graphics, so those are a lot more efficient as they are decoded and played on the client side and consume significantly less bandwidth.

Again, this feature is not and will never be available under Wayland because it knows nothing but rasterized image buffers. VNC under Wayland will be easier to implement and likely work faster than for X11 and that's it.

That's super cool, and it's sad we won't have that
Only thing I can think of is adding some Gallium state tracker to mirror the commands or something.
Regarding X11, note it isn't that support for sending drawing primitives was dropped, but it's more like a tree falling in the forest, if nobody uses it it doesn't matter that it's supported. And the big toolkits no longer do, so most people can't make use of it.
I'd expect most native GUI applications in Windows and OS X to use their drawing primitives because their toolkits are tailored to run on their own system only, I'd be surprised if they do it any other way.

[blacknova]

The most annoying thing missing from either X11 or Wayland right now is ability to detach your graphics session from one output and connect it to another, i.e. detach you session from local display/inputs and attach it to remote display server for remote access and than go back to local.
It actually should be possible for Wayland I think I've read news here about redirecting output here. But right now even screen share with GNOME is a no go unless you're logged in and unlocked the session.

[kreijack]

Help me understand:
The display server does not handle inputs and you are saying that is a bad thing?

Complicate the remote desktop :-)

Also, how is unifying UI elements in a single place - the gui framework - a disadvantage?

I see two main disadvantages:
1) each framework draws a different window decoration; but this is only an aesthetic problem
2) I continue to see the buttons on the title bar (maximize/resize/window menu) a way to allow the windows to cooperate together. Allowing the CSD complicate this kind of cooperation (see next point).

Also, I don't see why focus follow mode cannot be implemented with Wayland. You still have a compositor under Wayland that can do things

The most complex part of my sentence was "raise on click on the title bar": how the compositor implements this if it doesn't know anything about the "title bar" due to CSD ?

[kreijack]

You can pass Direct3D and OpenGL over RDP if necessary. And AFAIK RDP still use WMF/EMF as protocol payload, so it should support text and vector drawing.

Yes, I told the same thing. The point is that due to several different reasons this mode of working (even if it is still support) is "obsolete".

The reasons are basically two:
- the applications were faster to applying the (e.g.) font antialiasing than the X11/Windows GDI counterpart....
- the "vector" primitives are different in each OS. Instead passing a bitmap to the GUI is more standard. This simplify the developing of toolkits which work in multiple OS...

[blacknova]

Yes, I told the same thing. The point is that due to several different reasons this mode of working (even if it is still support) is "obsolete".

The reasons are basically two:
- the applications were faster to applying the (e.g.) font antialiasing than the X11/Windows GDI counterpart....
- the "vector" primitives are different in each OS. Instead passing a bitmap to the GUI is more standard. This simplify the developing of toolkits which work in multiple OS...

And that is exactly why we have so much issues moving to HIDPI displays. It is easier to pass bitmaps and assume that hardware is some fixed target, like GNOME just assume every display is 96DPI and even goes as far as enforce it so actual display DPI is ignored. So instead of fixed visible UI elements sizes in mm we have most elements sizes fixed in pixels, joy.

[mppix]

Complicate the remote desktop :-)

Generally speaking, remote desktop should be independent from remote desktop.
The biggest problem in the past was that X did not allow user permissions so we could not have multi-user remote desktop. There are early signs that this will change now.

I see two main disadvantages:
1) each framework draws a different window decoration; but this is only an aesthetic problem
2) I continue to see the buttons on the title bar (maximize/resize/window menu) a way to allow the windows to cooperate together. Allowing the CSD complicate this kind of cooperation (see next point).

We can debate probably debate forever if the title bar is the make or break of integrating different GUI frameworks. I would argue that Just slapping a bar on top of a window is less-than-useful. For example, most know the old Winamp music player. It uses a completely custom GUI that did not integrate at all. Putting a bar on top would just make it worse (to me).
I don't think I understand what you mean by cooperate. The compositor still manages windows.. and for example on gnome, windows "cooperate" fairly well (split scree etc).

The most complex part of my sentence was "raise on click on the title bar": how the compositor implements this if it doesn't know anything about the "title bar" due to CSD ?

Again, I don't think I understand what you mean here. "Raise on click on the title bar" is pretty much how every DE works...

[blacknova]

Again, I don't think I understand what you mean here. "Raise on click on the title bar" is pretty much how every DE works...

Not exactly - title bar in X11/Windows is WM managed area if you click on some buttons in window title your application might receive appropriate event or not if WM handle event by itself, while in Wayland whole window is application managed area and your application will get input event, not some DE/WM system event.