7 ms·

I love how simple this is- Barely 100 lines or C++ (ignoring comments). That's one thing that makes me prefer X11 over Wayland.

deleted 2y ago
[deleted]
EasyMark 2y ago
This was in the wrong thread…
ajross 2y ago
Yeah. I mean, not to deny the decades of arguments over its warts, but it's kind of amazing to me the extent to which X11 has emerged as, well, the simplest/best and most hackable desktop graphics environment available. You want to play a trick, it's right there. The ICCCM got a ton of hate back in the early 90's, but... no one else has an equivalent and people still innovate in the WM space even today.
- WD-42 2y ago
  Hackable is right. But not always in the positive sense of the word.
  - account42 2y ago
    It very much is. I expect programs running on my computer to not be restricted in how they can help me.
  - ajross 2y ago
    FWIW, the threat model you're imagining is an attacker being able to run code to display directly to the desktop using the lowest level native API. A local[1] code exploit at the level of an interactive user is already a huge failure in the modern world. Is that a reasonable argument against using X11? Sure, for some use cases. Is it a good argument for wayland/windows/OSX/whatever to do your tiling WM experimentation? Not really, those environments kinda suck for playing around with. [1] Or "local-ish", your system or a trusted remote has to have been compromised already. Untrusted X11 protocol still exists but is deliberately disabled (and often blocked) everywhere. Even ssh won't forward it anymore unless you dig out the option and turn it on manually.
    - boudin 2y ago
      Isn't any app that can access read the x11 socket able to read any input? It's not just running an explicitly malicious app but also the risk of compromising an app which can read the x11 socket (e.g. Firefox)
      - ajross 2y ago
        Yes, exactly. I'm just saying that the response to a remote browser exploit in firefox is more likely to be "YIKES ZERO DAY IN FIREFOX!!!!!" and not "well it's a good thing we're running it in windows so it can't screenshot other apps or inject key events". It's not like it's not a valid argument, just that it's sort of a nitpick. Security is hard, and defense in depth is a thing, but this particular attack surface is way, way back in the "depth" stack for a modern app deployment.
        superkuh 2y ago
        Javascript has managed to even ruin the linux desktop. Running every random JS application sent to your browser VM makes the browser insecure which means the entire computer can't be trusted. This is the reason things like the waylands enforce a smartphone like model of security where the user's applications aren't allowed to communicate or interact with other elements of the graphical desktop. Applications aren't trusted. So the user isn't trusted. A trade-off not worth it.
        quotemstr 2y ago
        Huh? What are you trying to say? There's no conflict between distrusting applications and trusting the user. Even on Android (which is pretty paranoid these days), you, the user, can still opt to trust apps with things like accessibility API access and background location. Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
        superkuh 2y ago
        >Why exactly should we perpetuate the insecure old single-privilege-level desktop model? Because after 10 years of heavy development none of the waylands have managed support simple things like screen readers. X11 supports screen readers and innumberable other vital accessibility features that wayland never will be able to. Some waylands might eventually develop extensions for their particular desktop but there won't ever be a way for wayland protocol because it can't. Security theater is more important than accessibility/usability for wayland that leaves many use cases and entire demographics of people out in the cold. So yes, X11, which is still the least worst option. Better to have the ability to do all things than have to wait decades+ for developers to write complex extensions to do things (and just for their DE, causing fragmentation).
  - l72 2y ago
    I find it very interesting how much our threat model has changed in the last 10-15 years. We no longer trust even local software, as we have to assume everything is now malicious. Commercial software from "reputable" companies can't be trusted to not pull a ton of analytics and personal data off your computer. We now have to worry about every piece of software being a keylogger and spying on other windows/applications and reporting back. We've had to give up so much flexibility. Wayland certainly focuses on plugging this hole, but it means we've lost all these cool utilities like this one. There was just so much you could do with devilspie, xdotool, and others to make sure my operating system and window environment worked for me. I still really miss X11's Zaphod mode, where you had two independent X sessions (:0.0 and :0.1) on two different monitors, with different window managers and different windowing rules. I miss the days of being able to trust my computer and trust my software.
    - singpolyma3 2y ago
      If you can't trust your locally installed software, everything is lost. I understand where this new threat model comes from for some people but I'd rather continue to avoid bad software sources than hamstring my OS in the hopes of avoiding malware I installed on purpose.
      - l72 2y ago
        I agree. But can you trust Zoom? What about Office or Photoshop? Can you trust Websites or your browser anymore? Even open source apps have analytics in them that may not be trustworthy anymore (firefox, audacity, ...).
        singpolyma3 2y ago
        This is why I don't run Zoom or Office or Photoshop or versions of Firefox or Audacity not distributed by Debian. Browser sandboxes pretty heavily though of course one does want to be a bit careful there too.
        jrm4 2y ago
        I teach online for a living, and -- yep Zoom through FIREFOX only. Coincidentally, it's also the best experience, for whatever reason it's the only on that supports virtual backgrounds on Linux for me? Neither Chrome nor Desktop seem to work for this.
- themerone 2y ago
  X11 is the opposite of simple and hackable. What you are thinking of as "hackable" is actually the result of it having a ton of legacy features that enable users to do neat tricks. Wayland breaks a lot of these tools because it is so much simpler than X.
  - RedShift1 2y ago
    Wayland is simple because it shoves all the responsibilities to somewhere else.
  - ajross 2y ago
    Lacking features isn't the same thing as "simpler", Wayland is great, but is very much a subset of the features implemented on an X11 desktop. Wayland doesn't do selections or provide any IPC mechanism of its own, much less something like an ICCCM that allows you to identify/target other users of the desktop and interact with them in a flexible way. In fact as I understand it the linked tool is in fact impossible to write in Wayland. Again, this isn't the fault of "Wayland", which is just a compositor framework. The complaint is that the ecosystem of "desktop" software which evolved around Wayland is an ad hoc monstrosity that lacks the unified structure that its ancestor had way back in the X11R5 days.
  - vidarh 2y ago
    By window manager started out as ~50 lines of Ruby copying an equivalent amount of C. You can say many things about Wayland, but it's "simple" from a point of view I for one really do not care about. Wayland may be "simple" in some respects, but it makes most of the things I care about doing unnecessarily complex.
    - bee_rider 2y ago
      Walyand probably would have been better if wlroots had been developed as a (whatever this means) first-party “built-in” library.
      - vidarh 2y ago
- anthk 2y ago
  The most hackable would have been a Lisp based desktop.
sim7c00 2y ago
there's very little code because there's very little error handling / sanity checking. not saying X11 isn't hackable and cool, but a lot of code gets bloated and complex (and robust!) by not assuming perfect usage. for example. run ./clipscreen 1 2 3 4
- splitbrain 2y ago
  True. If something goes wrong this will just crash. But to be fair, the only error handling I could think of would probably just exit with a vague error message... Pull requests to make it more robust welcome anyway!
  - xrd 2y ago
    To the parent, splitbrain just got you to QA this for him. The true cost of software is the maintenance and QA, and he got you to do free work, and here I am doing free work writing about it. How hard we BOTH just got pwned! </joke>
    - sim7c00 2y ago
      will work for food
  - sim7c00 2y ago
    haha yeah, its ok for a tool its really cool honestly :p just commenting on the 'so little code' might be good to check if the x y etc. are within the screen / set resolution perhaps.
asveikau 2y ago
The code is a little weird. There is no XLib event loop. It calls sleep(100) in a loop until it hits SIGINT. That will have high cpu usage for no reason.
- EasyMark 2y ago
  This is a sleep which allows the kernel scheduler to move to a new process and not a busy-wait so it will have very very low processor usage.
- splitbrain 2y ago
  FYI the code has been updated to use sigwait instead.
- diath 2y ago
  It will not, even adding just a 1ms sleep in a loop will drop CPU usage to barely noticeable levels, 10 wakes a second is barely anything for any CPU from the past 3 decades.
  - thwarted 2y ago
    This is what the pause(2) syscall was made for, waiting for a signal forever.
  - Too 2y ago
    It’s a good way to drain your battery on mobile devices, even if usage looks low. Not that this matters for this particular tool.
    - erickj 2y ago
      > Not that this matters for this particular tool. Then the code is perfectly appropriate.
      - quotemstr 2y ago
        It's a bad example for others and a bad habit to get into. If every program did this, we'd have trouble getting CPUs into deep idle states.
jchw 2y ago
This certainly is an elegant X.org party trick that can't be done easily in almost any other windowing system: creating a virtual Xrandr display that overlaps with existing physical displays. It's slightly awkward since if it exits outside of sigint it will leave a virtual output and no overlay window but that's a pretty minor issue. (All of that having been said, I would strongly advise to not over-index on SLoC as a measure of quality or elegance.) This flat-out can't be done in Wayland. Though all is not lost, you might not need this at all in Wayland. The standard way to capture the screen from an unprivileged process in Wayland is through desktop portals, and at least KDE supports a wide variety of different capture options including capturing a rectangle of the screen. I haven't tried, but I suspect this is even true when running X.org applications, thanks to XWaylandVideoBridge. I am not really thrilled about D-Bus stuff everywhere, but it is nice that you can pretty much override any screen capture behavior you want by changing the org.freedesktop.impl.portal.ScreenCast implementation: I think that's actually a step in a better direction versus having every application implement its own functionality for selecting capture targets.
- rnhmjoj 2y ago
  To me it's quite sad that for a lot of things, the "standard" way of doing something is not actually part of the standard (XDG portals, third party protocols, etc.). Yes, X.org is old, bloated, unmaintainable and whathever, but at least every desktop environment used the same X server implementation and the same tools worked everywhere. Besides the duplication of efforts in implementing the same stuff over and over, now someone developing somewhat non-trivial programs needs to be aware of the differences in supported features and non-standard extensions in all desktops, for example [1]. [1]: https://wayland.app/protocols/cursor-shape-v1#compositor-support https://wayland.app/protocols/cursor-shape-v1#compositor-sup...
  - jchw 2y ago
    I think Wayland had made some mistakes, no doubt. Cursor shape just should've been part of the protocol. Wayland has its fair share of misfires. That said, I understand what they were going for. They really wanted to make the compositor as small and simple as possible, so for example you would just use libwayland-cursor instead of bothering with cursors yourself. However there are a lot of ways libwayland-cursor worked out poorly... Not everyone agreed on how scaling should work, GTK4 ditched it for performance reasons, and overall it's just inconvenient for a lot of cases (languages other than C, sandboxing, etc.) And to make matters even worse, in practice every compositor needed to load and handle XCursor themes anyways... That said, I think that it's okay if Wayland doesn't own the majority of the Linux desktop stack the way X11 did. It's fine for compositors and their helpers to implement protocols from other projects, too. That way Wayland can be more applicable to graphical machines other than desktops without bringing unnecessary baggage. It'll always have trade-offs, of course, but I think it's far from the end of the world.
tapoxi 2y ago
In Wayland you just start a capture with the xdg-desktop-portal API and it notifies the user and let them select the area to capture.
- gchamonlive 2y ago
  Yes, but I believe op was refering to how interacting with all things Wayland seems to be more involved than with x11. I'm not sure this is indeed like this, I have zero experience in developing for Wayland, but I think this is what op meant.
  - yndoendo 2y ago
    Wayland is more focused on security. That onion layer right there will increase the complexity of usage. X11 doesn't have the extra abstractions to limit and prevent intrusive interactions with the desktop. Example of this would be where "runas /user:smith application.exe" is simple but does not work when a Windows Service is required to run an application as the user signed in. One must use Window's API to pull in the account's token and use more API to execute "application.exe". UltraVNC is a great source to see all the extras needed.
  - tapoxi 2y ago
    From a quick "how do I implement this in Python" with ChatGPT it seems to be about 30 lines, since most of the heavy lifting is done for you by the API.
    - Zetaphor 2y ago
      As someone who uses LLM's regularly to assist in code creation, take that output with a huge grain of salt until you've actually tested it. Especially as it relates to Wayland, I've pulled my hair out trying to get an LLM to assist with very similar tasks to this.
    - p_l 2y ago
      It means you got to tickle the banana, good luck making sure that the gorilla holding it is fine with that.
teekert 2y ago
Is it much more difficult under Wayland?
- favorited 2y ago
  Wayland intentionally makes this more difficult, because one of the security goals of the project is that (by default) Wayland clients shouldn't have visibility into other clients' window contents/events/etc. Of course, it still needs to be possible under Wayland, because there are plenty of legitimate use-cases (screenshots, screen sharing, video capture, etc.), but it was a non-goal to make it as simple as X. Wayland merged the image-capture-source and image-copy-capture protocol extensions earlier this year: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture https://www.phoronix.com/news/Wayland-Merges-Screen-Capture
  - enriquto 2y ago
    > Wayland intentionally makes this more difficult, some men just want to watch the world burn
    - favorited 2y ago
      And Wayland keeps their apps from spying on the rest of my screen!
      - enriquto 2y ago
        I never understood the rationale for Wayland's "security"... All the programs that I use (ls, rm, vim, ...) can "spy" to each other, and have unrestricted read/write access to all the bytes in my home directory. That's the whole point: I run these programs to control said bytes. What's so special about the pixels of my screen that the programs that manipulate them need to be protected from each other? If anything, the pixels in my screen seem less critical to security that the bytes in my disk. But Wayland insists in making that difficult, for incomprehensible reasons. Those are my pixels and I want to do what I decide, not what Wayland lets me to. I control my programs, not the other way round. If I decide that this program reads one pixel on my whole screen, or the global mouse position, or whatever, I see no point in forbidding me to do it. Of course, if I want to run some rogue program whose author I don't trust, I will do so inside a limited container. But this has nothing to do with graphical applications. I wouldn't like the rogue program to read my homedir either.

deleted 2y ago

[deleted]

EasyMark 2y ago

This was in the wrong thread…

ajross 2y ago

Yeah. I mean, not to deny the decades of arguments over its warts, but it's kind of amazing to me the extent to which X11 has emerged as, well, the simplest/best and most hackable desktop graphics environment available. You want to play a trick, it's right there. The ICCCM got a ton of hate back in the early 90's, but... no one else has an equivalent and people still innovate in the WM space even today.

WD-42 2y ago
Hackable is right. But not always in the positive sense of the word.
- account42 2y ago
  It very much is. I expect programs running on my computer to not be restricted in how they can help me.
- ajross 2y ago
  FWIW, the threat model you're imagining is an attacker being able to run code to display directly to the desktop using the lowest level native API. A local[1] code exploit at the level of an interactive user is already a huge failure in the modern world. Is that a reasonable argument against using X11? Sure, for some use cases. Is it a good argument for wayland/windows/OSX/whatever to do your tiling WM experimentation? Not really, those environments kinda suck for playing around with. [1] Or "local-ish", your system or a trusted remote has to have been compromised already. Untrusted X11 protocol still exists but is deliberately disabled (and often blocked) everywhere. Even ssh won't forward it anymore unless you dig out the option and turn it on manually.
  - boudin 2y ago
    Isn't any app that can access read the x11 socket able to read any input? It's not just running an explicitly malicious app but also the risk of compromising an app which can read the x11 socket (e.g. Firefox)
    - ajross 2y ago
      Yes, exactly. I'm just saying that the response to a remote browser exploit in firefox is more likely to be "YIKES ZERO DAY IN FIREFOX!!!!!" and not "well it's a good thing we're running it in windows so it can't screenshot other apps or inject key events". It's not like it's not a valid argument, just that it's sort of a nitpick. Security is hard, and defense in depth is a thing, but this particular attack surface is way, way back in the "depth" stack for a modern app deployment.
      - superkuh 2y ago
        Javascript has managed to even ruin the linux desktop. Running every random JS application sent to your browser VM makes the browser insecure which means the entire computer can't be trusted. This is the reason things like the waylands enforce a smartphone like model of security where the user's applications aren't allowed to communicate or interact with other elements of the graphical desktop. Applications aren't trusted. So the user isn't trusted. A trade-off not worth it.
        quotemstr 2y ago
        Huh? What are you trying to say? There's no conflict between distrusting applications and trusting the user. Even on Android (which is pretty paranoid these days), you, the user, can still opt to trust apps with things like accessibility API access and background location. Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
        superkuh 2y ago
        >Why exactly should we perpetuate the insecure old single-privilege-level desktop model? Because after 10 years of heavy development none of the waylands have managed support simple things like screen readers. X11 supports screen readers and innumberable other vital accessibility features that wayland never will be able to. Some waylands might eventually develop extensions for their particular desktop but there won't ever be a way for wayland protocol because it can't. Security theater is more important than accessibility/usability for wayland that leaves many use cases and entire demographics of people out in the cold. So yes, X11, which is still the least worst option. Better to have the ability to do all things than have to wait decades+ for developers to write complex extensions to do things (and just for their DE, causing fragmentation).
- l72 2y ago
  I find it very interesting how much our threat model has changed in the last 10-15 years. We no longer trust even local software, as we have to assume everything is now malicious. Commercial software from "reputable" companies can't be trusted to not pull a ton of analytics and personal data off your computer. We now have to worry about every piece of software being a keylogger and spying on other windows/applications and reporting back. We've had to give up so much flexibility. Wayland certainly focuses on plugging this hole, but it means we've lost all these cool utilities like this one. There was just so much you could do with devilspie, xdotool, and others to make sure my operating system and window environment worked for me. I still really miss X11's Zaphod mode, where you had two independent X sessions (:0.0 and :0.1) on two different monitors, with different window managers and different windowing rules. I miss the days of being able to trust my computer and trust my software.
  - singpolyma3 2y ago
    If you can't trust your locally installed software, everything is lost. I understand where this new threat model comes from for some people but I'd rather continue to avoid bad software sources than hamstring my OS in the hopes of avoiding malware I installed on purpose.
    - l72 2y ago
      I agree. But can you trust Zoom? What about Office or Photoshop? Can you trust Websites or your browser anymore? Even open source apps have analytics in them that may not be trustworthy anymore (firefox, audacity, ...).
      - singpolyma3 2y ago
        This is why I don't run Zoom or Office or Photoshop or versions of Firefox or Audacity not distributed by Debian. Browser sandboxes pretty heavily though of course one does want to be a bit careful there too.
      - jrm4 2y ago
        I teach online for a living, and -- yep Zoom through FIREFOX only. Coincidentally, it's also the best experience, for whatever reason it's the only on that supports virtual backgrounds on Linux for me? Neither Chrome nor Desktop seem to work for this.
themerone 2y ago
X11 is the opposite of simple and hackable. What you are thinking of as "hackable" is actually the result of it having a ton of legacy features that enable users to do neat tricks. Wayland breaks a lot of these tools because it is so much simpler than X.
- RedShift1 2y ago
  Wayland is simple because it shoves all the responsibilities to somewhere else.
- ajross 2y ago
  Lacking features isn't the same thing as "simpler", Wayland is great, but is very much a subset of the features implemented on an X11 desktop. Wayland doesn't do selections or provide any IPC mechanism of its own, much less something like an ICCCM that allows you to identify/target other users of the desktop and interact with them in a flexible way. In fact as I understand it the linked tool is in fact impossible to write in Wayland. Again, this isn't the fault of "Wayland", which is just a compositor framework. The complaint is that the ecosystem of "desktop" software which evolved around Wayland is an ad hoc monstrosity that lacks the unified structure that its ancestor had way back in the X11R5 days.
- vidarh 2y ago
  By window manager started out as ~50 lines of Ruby copying an equivalent amount of C. You can say many things about Wayland, but it's "simple" from a point of view I for one really do not care about. Wayland may be "simple" in some respects, but it makes most of the things I care about doing unnecessarily complex.
  - bee_rider 2y ago
    Walyand probably would have been better if wlroots had been developed as a (whatever this means) first-party “built-in” library.
    - vidarh 2y ago
anthk 2y ago
The most hackable would have been a Lisp based desktop.

sim7c00 2y ago

there's very little code because there's very little error handling / sanity checking. not saying X11 isn't hackable and cool, but a lot of code gets bloated and complex (and robust!) by not assuming perfect usage. for example. run ./clipscreen 1 2 3 4

splitbrain 2y ago
True. If something goes wrong this will just crash. But to be fair, the only error handling I could think of would probably just exit with a vague error message... Pull requests to make it more robust welcome anyway!
- xrd 2y ago
  To the parent, splitbrain just got you to QA this for him. The true cost of software is the maintenance and QA, and he got you to do free work, and here I am doing free work writing about it. How hard we BOTH just got pwned! </joke>
  - sim7c00 2y ago
    will work for food
- sim7c00 2y ago
  haha yeah, its ok for a tool its really cool honestly :p just commenting on the 'so little code' might be good to check if the x y etc. are within the screen / set resolution perhaps.

asveikau 2y ago

The code is a little weird. There is no XLib event loop. It calls sleep(100) in a loop until it hits SIGINT. That will have high cpu usage for no reason.

EasyMark 2y ago
This is a sleep which allows the kernel scheduler to move to a new process and not a busy-wait so it will have very very low processor usage.
splitbrain 2y ago
FYI the code has been updated to use sigwait instead.
diath 2y ago
It will not, even adding just a 1ms sleep in a loop will drop CPU usage to barely noticeable levels, 10 wakes a second is barely anything for any CPU from the past 3 decades.
- thwarted 2y ago
  This is what the pause(2) syscall was made for, waiting for a signal forever.
- Too 2y ago
  It’s a good way to drain your battery on mobile devices, even if usage looks low. Not that this matters for this particular tool.
  - erickj 2y ago
    > Not that this matters for this particular tool. Then the code is perfectly appropriate.
    - quotemstr 2y ago
      It's a bad example for others and a bad habit to get into. If every program did this, we'd have trouble getting CPUs into deep idle states.

jchw 2y ago

This certainly is an elegant X.org party trick that can't be done easily in almost any other windowing system: creating a virtual Xrandr display that overlaps with existing physical displays. It's slightly awkward since if it exits outside of sigint it will leave a virtual output and no overlay window but that's a pretty minor issue. (All of that having been said, I would strongly advise to not over-index on SLoC as a measure of quality or elegance.) This flat-out can't be done in Wayland. Though all is not lost, you might not need this at all in Wayland. The standard way to capture the screen from an unprivileged process in Wayland is through desktop portals, and at least KDE supports a wide variety of different capture options including capturing a rectangle of the screen. I haven't tried, but I suspect this is even true when running X.org applications, thanks to XWaylandVideoBridge. I am not really thrilled about D-Bus stuff everywhere, but it is nice that you can pretty much override any screen capture behavior you want by changing the org.freedesktop.impl.portal.ScreenCast implementation: I think that's actually a step in a better direction versus having every application implement its own functionality for selecting capture targets.

rnhmjoj 2y ago
To me it's quite sad that for a lot of things, the "standard" way of doing something is not actually part of the standard (XDG portals, third party protocols, etc.). Yes, X.org is old, bloated, unmaintainable and whathever, but at least every desktop environment used the same X server implementation and the same tools worked everywhere. Besides the duplication of efforts in implementing the same stuff over and over, now someone developing somewhat non-trivial programs needs to be aware of the differences in supported features and non-standard extensions in all desktops, for example [1]. [1]: https://wayland.app/protocols/cursor-shape-v1#compositor-support https://wayland.app/protocols/cursor-shape-v1#compositor-sup...
- jchw 2y ago
  I think Wayland had made some mistakes, no doubt. Cursor shape just should've been part of the protocol. Wayland has its fair share of misfires. That said, I understand what they were going for. They really wanted to make the compositor as small and simple as possible, so for example you would just use libwayland-cursor instead of bothering with cursors yourself. However there are a lot of ways libwayland-cursor worked out poorly... Not everyone agreed on how scaling should work, GTK4 ditched it for performance reasons, and overall it's just inconvenient for a lot of cases (languages other than C, sandboxing, etc.) And to make matters even worse, in practice every compositor needed to load and handle XCursor themes anyways... That said, I think that it's okay if Wayland doesn't own the majority of the Linux desktop stack the way X11 did. It's fine for compositors and their helpers to implement protocols from other projects, too. That way Wayland can be more applicable to graphical machines other than desktops without bringing unnecessary baggage. It'll always have trade-offs, of course, but I think it's far from the end of the world.

tapoxi 2y ago

In Wayland you just start a capture with the xdg-desktop-portal API and it notifies the user and let them select the area to capture.

gchamonlive 2y ago
Yes, but I believe op was refering to how interacting with all things Wayland seems to be more involved than with x11. I'm not sure this is indeed like this, I have zero experience in developing for Wayland, but I think this is what op meant.
- yndoendo 2y ago
  Wayland is more focused on security. That onion layer right there will increase the complexity of usage. X11 doesn't have the extra abstractions to limit and prevent intrusive interactions with the desktop. Example of this would be where "runas /user:smith application.exe" is simple but does not work when a Windows Service is required to run an application as the user signed in. One must use Window's API to pull in the account's token and use more API to execute "application.exe". UltraVNC is a great source to see all the extras needed.
- tapoxi 2y ago
  From a quick "how do I implement this in Python" with ChatGPT it seems to be about 30 lines, since most of the heavy lifting is done for you by the API.
  - Zetaphor 2y ago
    As someone who uses LLM's regularly to assist in code creation, take that output with a huge grain of salt until you've actually tested it. Especially as it relates to Wayland, I've pulled my hair out trying to get an LLM to assist with very similar tasks to this.
  - p_l 2y ago
    It means you got to tickle the banana, good luck making sure that the gorilla holding it is fine with that.

teekert 2y ago

Is it much more difficult under Wayland?

favorited 2y ago
Wayland intentionally makes this more difficult, because one of the security goals of the project is that (by default) Wayland clients shouldn't have visibility into other clients' window contents/events/etc. Of course, it still needs to be possible under Wayland, because there are plenty of legitimate use-cases (screenshots, screen sharing, video capture, etc.), but it was a non-goal to make it as simple as X. Wayland merged the image-capture-source and image-copy-capture protocol extensions earlier this year: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture https://www.phoronix.com/news/Wayland-Merges-Screen-Capture
- enriquto 2y ago
  > Wayland intentionally makes this more difficult, some men just want to watch the world burn
  - favorited 2y ago
    And Wayland keeps their apps from spying on the rest of my screen!
    - enriquto 2y ago
      I never understood the rationale for Wayland's "security"... All the programs that I use (ls, rm, vim, ...) can "spy" to each other, and have unrestricted read/write access to all the bytes in my home directory. That's the whole point: I run these programs to control said bytes. What's so special about the pixels of my screen that the programs that manipulate them need to be protected from each other? If anything, the pixels in my screen seem less critical to security that the bytes in my disk. But Wayland insists in making that difficult, for incomprehensible reasons. Those are my pixels and I want to do what I decide, not what Wayland lets me to. I control my programs, not the other way round. If I decide that this program reads one pixel on my whole screen, or the global mouse position, or whatever, I see no point in forbidding me to do it. Of course, if I want to run some rogue program whose author I don't trust, I will do so inside a limited container. But this has nothing to do with graphical applications. I wouldn't like the rogue program to read my homedir either.