mtp as in media transfer protocol? i fail to see what this has to do with the display server. and what do you mean with web transparency? never heard that term and google does not give any infos. If you mean something like network transparency, wayland can do that with e.g. waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe). but not tested myself tbh.
OK, I use GNOME on Wayland on EndeavourOS and have no problems regularly running a script in my phone’s internal storage root directory. Go file a bug report to your distro, or at least provide some details.
mtp has nothing to do with the display server. X11 has no mtp function either. its completely independent from that.
and i can only talk about KDE, but it has a own solution integrated which then mounts android folder in its file explorer (dolphin) while unfortunately blocking mtp over CLI at the same time. you get an “likely in use by GVFS or KDE MTP device handling already” error then.
It is possible of course that this is a thing that happens only under KDE wayland, but not because it is wayland itself but because the wayland version of KDE is maybe newer or was configured differntly by the devs.
that said, if it does not work as expected, report it as bug. usually things are fixed very quickly.
I don’t see how this is a Wayland problem. X11 has no desktop automation integrated either. You had to use third party tools for that like Autokey. And admittedly, there is still no comparable replacement for Wayland as far i know (maybe KDE scripts? https://develop.kde.org/docs/plasma/kwin/api/ or https://github.com/ReimuNotMoe/ydotool ?). But that is because nobody has fully build one yet, not because some inherent absence of necessary wayland functions.
It actually is because of Wayland design. In their quest for “security” they’ve made it impossible for automation and accesibility tools to do their job.
It’s a glaring omission in Wayland going forward, for zero gain. Most of the touted Wayland security advantages are hogwash.
I mean if it’s goal was to prevent scripts from using the graphics env maliciously then it seems to have made some progress if you can’t even automate it with good intentions
We need to keep a balance between security and convenience, to avoid systems becoming too awkward to use. Wayland tipped this balance too far on the side of security. Malicious local exploitation of the graphics stack has never been a big issue; consider the fact that someone or something would need to compromise your own account locally, at which point they could do much worse things than moving your windows around. It’s not that the security threat doesn’t exist, it’s that Wayland has approached it at the wrong end and killed a lot of useful functionality in the process.
Also consider that this issue has existed for the entire history of desktop graphics on *nix and nobody has ever deemed it worth to destroy automation for it. If it were such a grave security hole surely someone would have raised the alarm and fixed it during all this time.
My opinion is that Wayland has been using this as a red herring, to bolster its value proposition.
Yup, or even a simple notify-send. Trying to work out which environment variables are needed to get the damn thing to focus on the window in question which may or may not be an X11 window within Wayland. The magic formula I’ve learned so far:
(oh and sometimes you might need to preface that all with a sudo, oh and there’s no guarantee that the Display is at :0, even if no other display is in use). Eaaazyyy peaaaazyyy
I will say that wtype is the one wayland automation tool that does not need any preamble. It just works out of the box, genuinely good engineering by the developers on that project.
deleted by creator
mtp as in media transfer protocol? i fail to see what this has to do with the display server. and what do you mean with web transparency? never heard that term and google does not give any infos. If you mean something like network transparency, wayland can do that with e.g. waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe). but not tested myself tbh.
deleted by creator
OK, I use GNOME on Wayland on EndeavourOS and have no problems regularly running a script in my phone’s internal storage root directory. Go file a bug report to your distro, or at least provide some details.
mtp has nothing to do with the display server. X11 has no mtp function either. its completely independent from that.
and i can only talk about KDE, but it has a own solution integrated which then mounts android folder in its file explorer (dolphin) while unfortunately blocking mtp over CLI at the same time. you get an “likely in use by GVFS or KDE MTP device handling already” error then.
It is possible of course that this is a thing that happens only under KDE wayland, but not because it is wayland itself but because the wayland version of KDE is maybe newer or was configured differntly by the devs.
that said, if it does not work as expected, report it as bug. usually things are fixed very quickly.
Or try using any form of desktop automation… which is a show-stopper and it doesn’t look like Wayland plans to do anything about it any time soon.
I don’t see how this is a Wayland problem. X11 has no desktop automation integrated either. You had to use third party tools for that like Autokey. And admittedly, there is still no comparable replacement for Wayland as far i know (maybe KDE scripts? https://develop.kde.org/docs/plasma/kwin/api/ or https://github.com/ReimuNotMoe/ydotool ?). But that is because nobody has fully build one yet, not because some inherent absence of necessary wayland functions.
It actually is because of Wayland design. In their quest for “security” they’ve made it impossible for automation and accesibility tools to do their job.
It’s a glaring omission in Wayland going forward, for zero gain. Most of the touted Wayland security advantages are hogwash.
I mean if it’s goal was to prevent scripts from using the graphics env maliciously then it seems to have made some progress if you can’t even automate it with good intentions
We need to keep a balance between security and convenience, to avoid systems becoming too awkward to use. Wayland tipped this balance too far on the side of security. Malicious local exploitation of the graphics stack has never been a big issue; consider the fact that someone or something would need to compromise your own account locally, at which point they could do much worse things than moving your windows around. It’s not that the security threat doesn’t exist, it’s that Wayland has approached it at the wrong end and killed a lot of useful functionality in the process.
Also consider that this issue has existed for the entire history of desktop graphics on *nix and nobody has ever deemed it worth to destroy automation for it. If it were such a grave security hole surely someone would have raised the alarm and fixed it during all this time.
My opinion is that Wayland has been using this as a red herring, to bolster its value proposition.
Technically i think the worst they could do would be to record your screen. (Barring some extra fancy exploits or something.)
Yup, or even a simple
notify-send. Trying to work out which environment variables are needed to get the damn thing to focus on the window in question which may or may not be an X11 window within Wayland. The magic formula I’ve learned so far:(oh and sometimes you might need to preface that all with a
sudo, oh and there’s no guarantee that the Display is at:0, even if no other display is in use). Eaaazyyy peaaaazyyyI will say that
wtypeis the one wayland automation tool that does not need any preamble. It just works out of the box, genuinely good engineering by the developers on that project.