Screenshot delay with select option not working intuitively

[kucharskim]

scrot first tries to select then does the delay, I think from user experience perspective, it should first wait and sleep for the delay and then allow user to select area for screenshot. In practice I often do sleep 5; scrot -s instead of scrot -d5 -s

[kucharskim]

This was reported at the time on:

$ scrot -v 
scrot version 1.7

[guijan]

Yes, I actually found the same thing weird while working on a PR. If we know what will be on the screen at a particular moment in the future, it's probably because it's on the screen now and we can screenshot it now. If we don't know what will be on the screen in the future, the current behavior is useless. It's also the case that when using scrot interactively, immediately showing a selection rectangle means the terminal that scrot is in is on the screen, possibly obscuring what is being screenshotted. I support this change.

There was the detail that the current behavior allows taking a screenshot of the mouse pointer while using a selection rectangle, but I don't think that's important, or that we should support drawing a rectangle both before and after the delay. It might also be fixable but I'm not familiar with GUI programming.

[kucharskim]

I didn't do a lot of thinking about it, but I don't get why delay would be needed after the selection, so I don't see what flow my proposal would break.

[N-R-K]

The FAQ (number 2) mentions one https://github.com/resurrecting-open-source-projects/scrot/blob/master/FAQ

One other situation where it's useful, and I've faced this situation in practice, is when you're trying to take a screenshot of some pesky UI element that only shows itself when the mouse cursor is at a certain place.

Adding another flag to specify when the delay happens will take care of both use cases, I think. (Although the unix mindset in me thinks why bother when sleep 5; scrot -s works already).

[guijan]

take a screenshot of some pesky UI element that only shows itself when the mouse cursor is at a certain place.

Maybe combining -f with -s would fix that use case?

[N-R-K]

Maybe combining -f with -s would fix that use case?

I don't think it would. Switching away to a terminal will make the element disappear. And even if you bind it to a key - a lot of these elements disappear as soon as there's any keypress.

[kucharskim]

The FAQ (number 2) mentions one https://github.com/resurrecting-open-source-projects/scrot/blob/master/FAQ

Ah, make sense, good use case.

[N-R-K]

I'm thinking of adding something like --delay-select which will delay the selection also (if active). Does anyone have ideas for a better long-opt name?

I'm also thinking of keeping this a long-opt only, unless someone can suggest a sensible short-opt that isn't taken already.

[kucharskim]

Looking at free single letters, nothing intuitive comes to mind :/ I would go for uppercase E letter:

  -E, --delay-select

[guijan]

I don't really like the solution being proposed here but I'm about to free up -S in #231

[kucharskim]

Well, if -S would be available, I would definitely recommend that.

[N-R-K]

Any feedback on the documentation wording is welcome on #238.

Well, if -S would be available, I would definitely recommend that.

I'm not comfortable removing an existing functionality out of the blue (see: https://github.com/resurrecting-open-source-projects/scrot/pull/231#issuecomment-1474653258), so for now, I've made --delay-select a long-opt only flag.

In the future, if -S becomes available, then I think it would make a good fit too.