KDE Plasma 5.20 To Bring Working Screen Recording / Screencasting On Wayland

[Aryma]

linux is in sorry state

[bug77]

Like it should be.

KDE is a giant minefield and a UI/UX clusterfuck. It's a badly written tech demo. Which is sad, because the underlying technology (Qt) is all-around wonderful and a pure joy to write against.

(Source: am past KDE user, minor contributor and C++/Qt developer.)

You can fault KDE to no end (and probably rightly so in some cases), but my problem is Gnome has always felt awkward to use. And I've been giving it chances since 2000 (give or take).
But it's because I know stuff that works for others doesn't work for me (and vice-versa) that I don't talk Gnome down.

[bug77]

Problem with lethal attacks is that _unknown_ ones tend to kill you.
Besides, without even looking around for examples, I know that your statement is cr*p.
X11 is mini-OS in itself, without any concept of safety separation.

If (and that's a big if) there were hidden attacks against X, there will be against Wayland, too. I mean, really, process isolation? That's just one additional hurdle for attackers, not a foolproof defense.
Of all the benefits Wayland may bring, security is at the very bottom of my list.

[skeevy420]

Like it should be.

KDE is a giant minefield and a UI/UX clusterfuck. It's a badly written tech demo. Which is sad, because the underlying technology (Qt) is all-around wonderful and a pure joy to write against.

(Source: am past KDE user, minor contributor and C++/Qt developer.)

And GNOME is a crappy attempt at an Android clone.

The Home Screen? Crappy version of what Android does. Not much better than enabling the hacky multitasking and windows options on some Android devices.

The App Drawer? Exactly what Android does; only with a lot more wasted space.

It even has a crappy hot corner for the Recent Apps screen...So does Plasma and I disable that too because I don't need that screen when I have a functional taskbar.

Even the GNOME focused distributions are having this trend where they are switching to sandboxed programs that are from a centralized repository (Flats and Snaps) which is closer to what Android offers when compared to a traditional Linux package manager like Apt, Dnf, or Pacman. While some KDE programs are going that way, at least Discover and pkcon don't force a person into using Snaps like on Ubuntu.

But between Ubuntu + Snaps and Fedora Silverblue + Flatpak, I'm sure there are others, but two of the biggest GNOME players changing to "centralized app repositories that runs in a local sandbox", just like what Android does, really doesn't help with the GNOME is an Android Clone argument.

[oiaohm]

And GNOME is a crappy attempt at an Android clone..

Wrong platform. Gnome design choices go after Apple not Android in a lot of ways.

Even the GNOME focused distributions are having this trend where they are switching to sandboxed programs that are from a centralized repository (Flats and Snaps) which is closer to what Android offers when compared to a traditional Linux package manager like Apt, Dnf, or Pacman. While some KDE programs are going that way, at least Discover and pkcon don't force a person into using Snaps like on Ubuntu.

There is some interesting history here.

https://source.android.com/security/app-sandbox

Android is running applications per individual user. This is not how flatpak or snap does it. Flatpak and Snap is closer to how OS X DMG files do it. Yes Snap using loopback files to mount is really close to how OS X DMG files do it they are also loopback mounts.

Also traditional package managers get questionable to say the least as the Linux world has developed a lot of different package managers
https://en.wikipedia.org/wiki/NixOS Nix OS is from 2003 this is 5 years before android and does have a lot in common with how flatpak ostree does things.

Centralised repository with third party repository support applies equally to what you call traditional package managers and flatpak. Third party repositories it possible with Android so at this point everything is looking close. Snaps is a very different different issue will get to latter on..

There are two major repositories of flatpaks and they are done in two different ways.

The fedora flatpak repository is flatpak remote-add fedora oci+https://registry.fedoraproject.org note the oci bit. That open container image format.
and flathub is ostree repository done by flatpak-manager. Anyone just like the other package managers of history to setup their own repos with flatpak.

Of course flatpak project provides all the instructions if you wish to setup either repo type as your own private flatpak repo at no cost.

Snap on the other hand that is fully controlled repo where you will end up screwed.

https://forum.snapcraft.io/t/external-repositories/1760/189

Yes 2017 starts with a half assed promise that Distributions could decide to run their own snap repository by custom patching snapd coming forward to-day where it pay 15K a year for your own private space on Canonical servers. This makes Android store look cheap. So snap and flatpak really are very different beasts.

Yes snaps are basically centralised repository with no third party support. Please note even with Android you can use f-droid to install android APK files built by a independent third party to google. Snaps are hell load closer to IOS appstore. I would not compare snaps to Android that the wrong impression Snaps are horrible comparable to the IOS app-store system. There is a lot of horrible stuff coming from apple into the Linux world.

[Brane215]

Of all the benefits Wayland may bring, security is at the very bottom of my list.

This is why they don't care about your opinions.

[tildearrow]

I would not be so smug with the (and other data query). You should have stopped at screen recording. Lets go into the other data query region.

https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/

Why do we have AT-SPI2 running by dbus. Because X11 protocol is in fact unable to transfer all the data accessibility applications need to function that why AT-SPI2 exists. So accessibility application needing screen-capture has need to support two system interfaced protocols dbus and x11. The new way wayland solutions need is doing screen capture is like AT-SPI2 that it will work under X11 and Wayland by dbus this now reduces accessibility applications to 1 protocol dbus.

While AT-SPI2 looks like the solution. The problem is that it looks very tied to GNOME. But this is to be expected considering GNOME is pretty much the gold standard implementation of the Wayland protocol. This is why GNOME is more stable. Wayland was made by them for them. And that will be the case for all eternity. The problem is KDE XFCE LXDE LXQt Sway all the other desktops exist. Like it or not they do and using a GNOME protocol for it is odd. Yes they have been trying to move the protocol to FreeDesktop. Which is a good thing. However I feel there are a few things tied to GNOME there. Read the page. There are GNOME links. Come on.

Yes wayland protocol makes it impossible to screen record so forcing development of a dbus side protocol that permission system to access. Lot of ways this is the right thing.

Yes this is apparently the only solution. Now please do not serve frames over dbus considering it is not an optimal protocol. Maybe references to then but yeah. Thankfully everyone is using PipeWire so things are ok.

I know moving all data queries people want to perform on-top of dbus instead of X11 means upsetting their code.

Exactly. And the problem is that there is no easy way to use dbus without bringing bloat to the table. Maybe Python is an exception. But for C++ you are pretty much lost. Tie your application to GNOME Qt or systemd. Otherwise get lost in confusion land with libdbus.

Please note those using X11 to screen capture could be screwed over as well if people started using X11 securely. Xephyr and Xnest have you ever though why they they exist. That right you have not be able to screen capture correctly when X11 applications have been sandboxed either. Securish versions of X11 have not been that popular either think they end up running each application in like Xnest/Xephr so they cannot do a complete screen capture only access windows the application created itself. So the wayland problems in fact exist under secure versions of X11 as well. So none of the problems Wayland is causing are new in fact all existed over a 2 decade before Wayland was even a idea with secure versions of X11 servers.

Please note that you are trying to make an excuse. Really all you are doing is making an excuse to pretend Wayland compositors do not have the screen recording problem. And it is hard to talk with you because the amount of text you write is so large that I have to bring filler text to be competitive. I do not understand who would use X11 sandboxing in a normal environment. You say that will be the main use case. Maybe in your bubble. Want to know how many people do that. Less than one percent guaranteed. I would write more but I do not have to write more because I am going straight to the point. No need to write more. No need to write more. Filler text to write the same amount of text as oiaohm. Really filler text.

Do we want our general desktop to be a secure designed desktop. I would say yes. Wayland is causing some issues that have been ignored for 2 decades to be now be fixed.

...in turn causing more issues. The need to develop a separate mechanism for data query is an example. Would dbus be required. Yes. Because of course it is the solution for it. Not that it is a problem. It should be fine as long as we still can make script for messing around Wayland windows.

[skeevy420]

Wrong platform. Gnome design choices go after Apple not Android in a lot of ways.

Maybe so, but I still see an Android tablet home screen more than I do a PC desktop when I look at plain, default Gnome.

We don't need to quote all that.

Damn, thanks, I wasn't expecting that level of a response.

[bug77]

This is why they don't care about your opinions.

Thank you, I would have been lost without that witty remark

[oiaohm]

While AT-SPI2 looks like the solution. The problem is that it looks very tied to GNOME. But this is to be expected considering GNOME is pretty much the gold standard implementation of the Wayland protocol. This is why GNOME is more stable. Wayland was made by them for them. And that will be the case for all eternity. The problem is KDE XFCE LXDE LXQt Sway all the other desktops exist. Like it or not they do and using a GNOME protocol for it is odd. Yes they have been trying to move the protocol to FreeDesktop. Which is a good thing. However I feel there are a few things tied to GNOME there. Read the page. There are GNOME links. Come on.

Nothing like a incorrect rant in this case I cannot exactly blame you because most of the central AT-SPI2 sites have not been properly updated in ages. AT-SPI2 is neutral.

https://wiki.debian.org/accessibility-devel

This is walking though debian to run it on. KDE LXQt and Sway you can turn AT-SPI2 support on by the Qt toolkit. XFCE can have it turns on just has a different on switch to gnome.

Really tildearrow you need top drop this gnome only stupidly over AT-SPI2. The reality is these days that text you see rendered on screen in X11 by the X11 server is a rendered image. The only way a screen reader for the blind under Linux can get what a section of text says is either OCR screen image from X11 or use AT-SPI2 to get what the text is before it was turned to a image. OCR screen images is not dependable due to all the different font rendering solutions. So basically if a windows manager/wayland compositor does not support AT-SPI2 it does not support the people with disabilities at all. X11 protocol these days is fairly much useless for proper application remote control.

Tildearrow there no competing protocol on Linux to AT-SPi2 the reality is X11 and Wayland are not competition to AT-SPI2.

Linux Desktop does not have a place as a company default desktop if it does not support people with disabilities.

Tildearrow the problem here is AT-SPI2 is not that it looks like a solution. Turns out for a particular usage case on the Linux Desktop AT-SPI2 is the only solution there is no competition at all.

Yes this is apparently the only solution. Now please do not serve frames over dbus considering it is not an optimal protocol. Maybe references to then but yeah. Thankfully everyone is using PipeWire so things are ok.

Heres a good question how useful to a people with disabilities is a remote desktop done using pipewire screen capture or remote X11. Turns out not very useful. The information they need is in fact is not provided either way. AT-SPI2 can give you where the clickable items are and text of what they are.

So in a lot of ways PipeWire screen capture is incomplete information so is X11 screen capture.

Please note if you apply this test to Microsoft RDP you run into the same problem is built for the totally able bodied people.

Exactly. And the problem is that there is no easy way to use dbus without bringing bloat to the table. Maybe Python is an exception. But for C++ you are pretty much lost. Tie your application to GNOME Qt or systemd. Otherwise get lost in confusion land with libdbus.

What you have missed X11 protocol use to be more useful like when X11 server use to render fonts before it passed that complete to clients that now render text to images before sending to it. X11 has been debloated tot he point of being useless for the people with disabilities or those after perfect script control of graphical applications. So yes we have to bring some bloat back to bring back some features. The issue with dbus toolkits is a problem that still need to be properly addressed.

Please note that you are trying to make an excuse. Really all you are doing is making an excuse to pretend Wayland compositors do not have the screen recording problem.

Lot of ways it right its not Wayland compositors because the information todo history X11 screen recording is not there and it no there in modern X11 servers either. To how useful a screen capture is how much different would it make it you were just capturing the hdmi out or doing the conversion in graphics card. About the only useful information a Wayland compositor has is where a application window is on screen. Turns out modern X11 server and X11 Windows manager has basically the same level of useless information. For useful information like what section of application window is in fact clickable that over in the AT-SPI2 instead of X11 protocol these days.

Its really about time you wake up what you call screen recording is not what was X11 screen recording 40 years ago when the X11 server still rendered fonts and draw stuff on screen.

I do not understand who would use X11 sandboxing in a normal environment. You say that will be the main use case. Maybe in your bubble. Want to know how many people do that. Less than one percent guaranteed.

X11 based point of sales, atms, flight control computers... These users out number your normal Linux desktop users almost 20 to 1. Also what is really fun is all these usage cases you don't want screen capture if you need to screen capture you take a photo with camera in hand. Of course this causes a priority problem the one with 20 times more market share gets their wanted features worked on first.

...in turn causing more issues. The need to develop a separate mechanism for data query is an example. Would dbus be required. Yes. Because of course it is the solution for it. Not that it is a problem. It should be fine as long as we still can make script for messing around Wayland windows.

Lot of ways tildearrow you have ignored how much X11 screen recording has weakened over the last 30 years. Wayland cutting of the old X11 interfaces that really don't provide the information they use to is a good thing. Forcing people to move to AT-SPI2 where there is more information. Transitions always hurt.