Do we still need this check? It sounds like a touch-only device wouldn't render any selection because of this.

Originally posted by @emersion in #63 (comment)

I just started playing around with a graphics tablet on sway, and figured that it might be nice to use slurp to set mappings for tablet input, e.g.

# sway.conf

bindsym $mod+t exec swaymsg "input type:tablet_tool map_to_region $(slurp -f \"%x %y %w %h\")"

For this usecase it would however be useful to fix the aspect ratio of the selection to that of the tablet. Thus, I'd like to propose adding an --aspect <ratio> option that implements this behaviour. Could this be added? If yes, I might look into implementing it myself. I've essentially no knowledge of sway/slurp/wayland internals, though, so if someone else would go ahead, I'd appreciate it a lot. Thanks!

First off, thanks for creating such a useful tool for wayland desktops! The only thing missing to make it a complete replacement for me would be the ability to simply click on a window to select its coordinates, like slop does on x desktops. The feature is pretty handy to quickly grab something without having to manually select the exact border.

Add an option for a prompt text, ie. text displayed to explain to users what to select.

Still unsure how it should look like.

Ref emersion/xdg-desktop-portal-wlr#121

A mode to select a single coordinate instead of an area could be useful to implement various utilities for sway (using ipc get_tree) or other wayland compositors.

• color picker
• screenshot of selected window.
• get information about selected window (class, role, app_id, geometry...)
• kill window under cursor (i.e. xkill)

Maybe we should have an option to force slurp to read from stdin, even if stdin is a TTY.

Originally posted by @emersion in #63 (comment)

slurp doesn't handle negative coordinates correctly:

❯ slurp
4294966849,4294966464 1371x567

Background: I have one display with negative coordinates, to work around an issue in sway.

❯ swaymsg -t get_outputs | jq -r '.[] | select(.active) | .rect | "\(.x),\(.y) \(.width)x\(.height)"'      
0,0 1600x900
-480,-1200 1920x1200

Related but distinct: #37

hacksaw can draw full screen crosshairs which can help when choosing the origin of the selection. It would be nice to have those in slurp as well.
The gif in the readme demonstrates this feature nicely.

For some reason slurp uses the default arrow cursor.

After #50 was merged, I wanted to try out the new feature and compiled the git version on my laptop. However, as soon as I touch the touchscreen after I started slurp, I get a segmentation fault. Unfortunately I don't know how to produce a proper backtrace since I can't type bt while slurp is still in front of my entire screen. This is the best I've gotten by killing slurp from another tty after the segmentation fault:

(gdb) run
Starting program: /home/msrd0/git/slurp/build/slurp 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
move_seat (seat=0x555555570440, surface_x=131094, surface_y=96053) at ../main.c:34
34              int x = wl_fixed_to_int(surface_x) + seat->current_output->logical_geometry.x;
(gdb) bt
#0  move_seat (seat=0x555555570440, surface_x=131094, surface_y=96053) at ../main.c:34
#1  0x0000555555559766 in touch_handle_motion (data=<error reading variable: Cannot access memory at address 0x7fffffffda58>, touch=<error reading variable: Cannot access memory at address 0x7fffffffda50>, 
    time=<error reading variable: Cannot access memory at address 0x7fffffffda4c>, id=<error reading variable: Cannot access memory at address 0x7fffffffda48>, x=<error reading variable: Cannot access memory at address 0x7fffffffda44>, 
    y=<error reading variable: Cannot access memory at address 0x7fffffffda40>) at ../main.c:308
Backtrace stopped: Cannot access memory at address 0x7fffffffda78
(gdb) q

If I can provide any other debugging help please let me know.

Hovering over a notification ( dunst ) breaks the selection everytime. Dunst window is always above the slurp overlay on the screen, is there a way to fix it or it is a dunst problem ?

When you run slurp, the cursor will remain regular until you move it, and then, it will turn into the crosshair.

This causes a problem when running slurp and directly doing a selection, the selection will not be highlighted and the resulting selection will have an empty x and y value, like this: 0,0 1144x753

Steps to replicate:

1. Open a terminal and run slurp
2. Don't move the cursor
3. Notice the cursor still being regular, not a crosshair
4. Press the primary mouse button and drag a selection
5. Notice the selection not being highlighted and the result having x/y values set to 0

We need to create a new layer surface when an output is hotplugged.

Or maybe it's not worth it.

If I select from any corner to the opposite corner, it always selects one pixel short on both axes. My screen is 1600x900, but the output of slurp is limited to 0,0 1599x899

The version I have installed is 1.2.0, and I'm using it with sway 1.5.1-r1

I rarely use my computer with a physical mouse attached, so I need to use the touchpad to make selections. When selecting larger regions, the click-drag-release method of defining the region often doesn't work well (even when pointer movement is configured quite fast). Would you consider adding an alternative mode (i.e. a CLI option to switch to it) where the first click/tap sets the first corner, then the cursor could be moved freely with no button held, and the second corner would only be set after a second click/tap?

As with my other feature request, I might look into implementing it myself. I've essentially no knowledge of sway/slurp/wayland internals, though, so if someone else would go ahead, I'd appreciate it a lot. Thanks!

This would be useful for the output selection mode.

Currently if a user is clicking on a dropdown menu in an application (for example a browser), making a selection will unfocus the window and makes the dropdown close. This prevents taking screenshots (with grim for example) of the content of the dropdown menu. Is there a way to make a selection without losing focus of the window?

Slurp sometimes crashes after dragging the rectangle and releasing the mouse button.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcca6418ece in wl_proxy_marshal_constructor () from /usr/lib/libwayland-client.so.0
(gdb) bt
#0  0x00007fcca6418ece in wl_proxy_marshal_constructor () from /usr/lib/libwayland-client.so.0
#1  0x000055ba1356af55 in wl_shm_create_pool (wl_shm=0x55ba14c2a3b0, fd=4, size=8294400) at /usr/include/wayland-client-protocol.h:1683
#2  0x000055ba1356b281 in create_buffer (shm=0x55ba14c2a3b0, buf=0x55ba14c08b10, width=1080, height=1920) at ../pool-buffer.c:90
#3  0x000055ba1356b4f9 in get_next_buffer (shm=0x55ba14c2a3b0, pool=0x55ba14c08ad8, width=1080, height=1920) at ../pool-buffer.c:146
#4  0x000055ba1356a1c8 in send_frame (output=0x55ba14c08a80) at ../main.c:235
#5  0x000055ba1356a2fe in output_frame_handle_done (data=0x55ba14c08a80, callback=0x55ba14c36dc0, time=700815720) at ../main.c:263
#6  0x00007fcca4af11c8 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#7  0x00007fcca4af0c2a in ffi_call () from /usr/lib/libffi.so.6
#8  0x00007fcca641bf5f in ?? () from /usr/lib/libwayland-client.so.0
#9  0x00007fcca64186ca in ?? () from /usr/lib/libwayland-client.so.0
#10 0x00007fcca6419c0c in wl_display_dispatch_queue_pending () from /usr/lib/libwayland-client.so.0
#11 0x00007fcca641a05c in wl_display_roundtrip_queue () from /usr/lib/libwayland-client.so.0
#12 0x000055ba1356adca in main (argc=1, argv=0x7fffdbd24318) at ../main.c:518

When I use slurp to get an area on one of my external monitors, I end up getting the coordinates for the corresponding area on my primary built-in monitor instead.

EDIT: To be clearer, grim -g '<coords>' captures primary monitor instead.

sway version 1.1-rc1-2-g51c07779 (May 6 2019, branch 'master')

My monitor setup in config:

output eDP-1 pos 0 0 res 1920x1080 scale 1
workspace 1 output eDP-1
output DP-1 pos 1920 0 res 2560x1440 scale 1
workspace 9 output DP-1
output DP-3 pos 4480 240 res 1920x1200 scale 1
workspace 11 output DP-3
output VGA-1 pos 6400 56 res 1280x1024 scale 1
workspace 12 output VGA-1

This could be some misconfiguration or problem on my side, I'm not sure. In any case, I'm sure slurp used to work for me but at some point it appears to have gotten broken. In any case I guess this now when running slurp:

slurp
failed to create display

version info:

sway version 1.0-beta.2-133-gd06782c5 (Jan  9 2019, branch 'master')
wlroots version fe187fc887d5b62d47e81b25cfa1a67b0fa4cc16
slurp version 95d8ec7e6b706961ffba3705033a9f57636aa65c

I often need to screenshot tooltips in VS Code. When I do something like:

sleep 5; grim -g "$(slurp)" - | wl-copy

To paste somewhere to report a bug, slurp appears to be stealing focus away from the window, which makes the tooltip disappear (thus meaning grim screenshots after what I wanted to screenshot is gone).

This appears to happen only for XWayland clients, so in my case Chromium-based applications like VS Code, Chromium itself, etc. If I repeat this for the right-click menu of my terminal (which is VTE -> GTK -> Wayland directly), then I can properly select and screenshot the tooltip.

Is this inherent to the way XWayland applications detect focus, or would it be possible to prevent slurp from "stealing" focus away?

My workaround has been to not use slurp, and go edit my screenshot later, as grim itself doesn't "steal" focus.

pointer->cursor_surface is NULL at main.c:38.

• Slurp 1.3.1
• Sway 1.5.1

Running slurp and selecting region across multiple outputs results in this:

selection cancelled

-f "%x,%y %wx%h"

Might also want to add %o for the output name.

Use frame callbacks instead

Hello,

When trying to run slurp on Fedora 30, Gnome 3.32.2, I get the following error:

wl_registry@2: error 0: invalid version for global wl_output (4): have 2, wanted 3
compositor doesn't support zwlr_layer_shell_v1

Any help is appreciated!

Slurp(v1.3) lost its selection when a pointer is moved to other monitors.
I checked the version 1.2 has no problem.

Currently, slurp centers the border on the edge of the selection, rather than pushing it to the outside. This is especially noticeable when piping in predefined areas for selecting whole windows. This obscures the selected content when using thicker borders, and it's a bit confusing.
Both slop and hacksaw draw the border around the selection with no overlap.

It seems that when the selection cursor appears (crosshair) it's half the size of a normal cursor on a 4k display. Could this be a problem with the cursor theme? I tried elementary and adwaita cursor themes with the same result. How does slurp determine the size/theme of the crosshair cursor?

Blocked by a Sway bug: swaywm/sway#1862

i use slurp with grim to take screenshots.
it would be useful if you could exit slurp by pressing esc (as e.g. in macOS) to not take a screenshot.
e.g. when you wrongly pressed the screenshot button

looks weird, you see black edges on the screenshot, most likely becuase it also screenshots slurp

It has a lot of features worth borrowing, but there's one that I keep remembering about:

Before and during the selection process, there's a zoomed preview of the area your mouse is in, highlighting the pixel you're currently aiming at. Very useful for quick pixel-perfect screenshots, which I currently have to either redo a few times or edit with Pinta/GIMP. Was sorely missed in maim too.

A video of it in action (warning: loud music, &mute=1 is broken): https://youtu.be/NB32QYt8WfI?t=6

I imagine this is far from trivial to implement (since this will probably require taking a screenshot upfront, instead of just rendering an overlay), but decided to request it anyway, who knows.

When setting the output position in sway to a negative coordinate, slurp behaves buggy.
My configuration:

output VGA-1 pos 0 0
output DVI-I-1 pos 1600 -450

The selection is not placed where the user clicks:
https://user-images.githubusercontent.com/6215916/110844081-e7c8b200-82a0-11eb-98b9-feed5b89a04d.mp4

Rewriting the configuration to only use positive coordinates makes this issue disappear.

output VGA-1 pos 0 450
output DVI-I-1 pos 1600 0

I got XKB_DEFAULT_OPTIONS='compose:ralt,caps:swapescape' in my environment (using sway).

When I invoke slurp and try to cancel it with the Caps key nothing happens.
When I press the actual Esc key it gets cancelled, but caps lock gets triggered as well.

When trying to select with tap to click on a trackpad (quick double-tap and drag), any other interaction will immediately confirm the selection, including pressing a key on the keyboard or physically clicking the trackpad (even without releasing). This also prevents escape from cancelling the selection properly.
I am using the following in my sway config:

input type:touchpad {
    click_method clickfinger
    natural_scroll enabled
    tap enabled
}

It appears that the 1.2.0 release package at https://github.com/emersion/slurp/releases/download/v1.2.0/slurp-1.2.0.tar.gz is not at the same revision as the source code artifact. For instance, the -p option is not included.

man slurp(1)
COLORS
       Colors may be specified in #RRGGBB or #RRGGBBAA format. The # is op‐
       tional.

Specifying colors in -b -c and -s options with # prepended to RRGGBB or RRGGBBAA format outputs e.g.:
slurp: option requires an argument -- 's'
Ommiting # works as advertised.
Man entry is wrong about # being optional. It doesn't function if # is included in color definition.

Probably w/ wayland-cursor

This would allow users to avoid the need to perform intersection checks themselves on the coords printed by slurp.

1. Add the ability to label regions provided on stdin, e.g. 0,0 42x42 @top-left
2. Add a format specifier to print the selected input region label on stdout, e.g. -f "%l"

For instance, when selecting a Sway window, users could provide a label with the container ID, and make slurp print container IDs.

I am unable to run slurp on the latest build of Sway with wlroots on Arch Linux. Slurp fails to function and quits with the following error:

slurp: ../main.c:479: main: Assertion `cursor' failed.

Aborted (core dumped)

This is quite difficult to replicate. When using slurp to make a selection given the very specific scenario below, the start vertex (where the mouse is dragging from) will appear in the wrong place.

Steps to replicate:

1. Configure Sway such that you have two monitors, one above the other
2. Set the following environment variables:

export QT_QPA_PLATFORM=wayland-egl
export QT_WAYLAND_FORCE_DPI=physical

2. Open a tiling window of any kind on the left, and KeePassXC on the right (the only two applications it seems to happen with is KeePassXC as long as the above variables are set, and a Wayland compositor named Cage, suggesting that it only happens with Wayland applications)
3. Move your mouse to the very top right of the KeePassXC window. The crosshair should only be a pixel or two below the top of the screen, bearing in mind there's another monitor above.
4. Click and drag
5. Observe that the start vertex appears at the bottom centre of the screen

The screenshot shows what it looks like at step 5. The bottom left vertex behaves as the start vertex which is in the wrong place, because I started the selection at the top of the screen.

If you start slurp, then, without moving, click the mouse, then move the mouse, slurp doesn't know that the button is pressed already. This results in selections with no UI that start on 0,0.