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

[sinepgib]

1) each framework draws a different window decoration; but this is only an aesthetic problem

I'd say considering one of the selling points for Wayland is no lost frames and no tearing, it's part of the premise that we want to avoid aesthetic problems.

Maybe Wayland team think they can abstract away all these and do the transformation themselves after client applications output their bitmap. Or they may be doing what happened in GTK4 - axe subpixel AA and font hinting in text, then refuse to admit they are doing a disservice to users.

Most likely like you say but with Wayland saying nothing, just leaving that up for the compositor to decide.

[billyswong]

...

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.

...

This is the part I disagree with Wayland blueprint. The client application "not to know about the monitors" is not a solution to multi-head support.

Case 1: All monitors are in the same model or similar enough.
In this case X11 way of doing things is okay because all monitors are going to apply the same color profile and same dpi setting. There is nothing wrong with treating them as "one big unified item".

Case 2: Mixed DPI / Refresh Rate / Colour Profile / WCG / HDR / Orientation
In this case the "correct" bitmap is different for each monitor.
Outputting a HDR or WCG image / video to capable monitors is different from legacy monitors. Those new monitors are also all different in their actual capability in colour gamut / dynamic range. There are multiple ways to map wider gamut and higher range to narrower gamut and lower range. Different applications may want to choose different way of mapping.
Subpixel AA and font hinting for text can only be done when DPI and subpixel orientation is known. Even for the same monitor model, a different bitmap is required when the thing is rotated by 90 degrees. Cutting all these information away from client application? The output result is guaranteed to be worse than X11. At least X11 can give correct result for one of the monitors, not none of them.
Real time animation want to know the monitor refresh rate to vsync and prevent tearing. Video streaming want to know the same to provide the best high frame rate video but no higher than what the monitor(s) is/are capable. Without the refresh rate information, both will degrade in either energy efficiency or output quality.

Maybe Wayland team think they can abstract away all these and do the transformation themselves after client applications output their bitmap. Or they may be doing what happened in GTK4 - axe subpixel AA and font hinting in text, then refuse to admit they are doing a disservice to users.

A proper multi-head support shall let client applications know the monitor profiles individually and adapt accordingly.

[blacknova]

We have it for X11: https://xpra.org

I'll try it out.

[birdie]

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.

We have it for X11: https://xpra.org

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

[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]

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.

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

[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 ?

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