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.
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-sup...
for example. run ./clipscreen 1 2 3 4
Wayland breaks a lot of these tools because it is so much simpler than X.
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
A lot more work involved, though.
edit: Here you go https://github.com/Stengo/DeskPad
Shift+Click: select from currently selected item to clicked item
Ctrl+Click: add/remove clicked item to set of selected items
More useful shortcuts in https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti...
xrandr --setmonitor screenshare 2560/1x1440/1+0+0 none
geo=$(slop -f '%w/1x%h/1+%x+%y') && xrandr --setmonitor screenshare "$geo" none
xrandr --delmonitor screenshare
before this to seamlessly update the shared region — Chrome will immediately pick up the change and continue sharing the updated virtual monitor.
Awesome!
So I wrote a small tool that uses the xrandr extension to mirror an area to a virtual monitor which then can be shared.
See my blog post for some more details: https://www.splitbrain.org/blog/2024-10/11-introducing_clips...
https://askubuntu.com/q/150066#998435
However, both Xephyr/Xnest and "xrandr --setmonitor" create separate non-overlapping screen(s), which means sharing part of a window (say, browser sans chrome [1]) can't be done here, but is possible with OP's tool.
[1] EDIT: "chrome", as in - parts of browser's window other than webpage itself: tabs, URL bar, bookmarks, etc...
We, as engineers, can't expect everyone to know what OBS is, download it, learn in, and use it every day to enable their ability to share a sub-section of their monitor (regardless of its size.)
We, as engineers, _are_ expected to make our software easier to use and feature rich. Adding this capability into Zoom or Meet, etc. is a reasonable thing to expect from a software company of note. And people _do_ know what Zoom and Meet are, download them, learn them, and use them every day. Why not implement the feature directly into the software they're already using?
The app that we d like to share and both control is a browser (running on a machine on our LAN) so a browser extension would work too I guess.
