This is what the pause(2) syscall was made for, waiting for a signal forever.

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.

Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now.

Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.

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.

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.

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>

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.

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.

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.

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.

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.

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.

I'm not aware of company issued computer with x11. Is it really a thing ?

Sure, but the idea you can share multiple windows this way.

Can Google Meet (or hangout or w/e they call it now adays) do some of this?

Wow that is also very cool. For those wondering, this is what it looks like:

  $ sudo apt install slop
  $ slop
       <selects an area on screen>
  1719x1403+1080+277

this is just cmd+shift+5 in a Mac OS