Added selection via keyboard

[hew02]

I wasn't sure if the ignore keyboard option, as it stands, should now be enabled by default, for now I have kept the original intent. Obviously borrows for selx. Let me know if there need to be further adjustments. #369.

[N-R-K]

How is this supposed to work? I'm trying scrot --select but pressing arrow key just terminates the shot:

scrot: Key was pressed, aborting shot
scrot: no image grabbed

[hew02]

How is this supposed to work? I'm trying scrot --select but pressing arrow key just terminates the shot:

scrot: Key was pressed, aborting shot
scrot: no image grabbed

That's what I was referring to in my above comment, maybe not clear enough. As it is, scrot requires an additional flag to not exit with keyboard input: -i/--ignorekeyboard. Didn't want to touch things I wasn't directly working on but I wonder if it is in fact necessary.

[N-R-K]

scrot requires an additional flag to not exit with keyboard input: -i/--ignorekeyboard.

I see, that's certainly confusing. I'd expect ignore keyboard to... well ignore keyboard. I suggest adding a separate --keyboard/-K flag to enable keyboard control.

• No flags: default behavior.
• -i: follow existing behavior with -i and ignore keyboard.
• -K: allow keyboard control (new behavior).
• -i + -K: mutually exclusive, write an error message and exit.

[hew02]

I was wondering if diagonal movement would be nice as well?

[daltomi]

This PR would break the current behavior of being able to correct the start of the selection via keyboard and mouse, which is the most important part, in my opinion.

In other words, in the master branch you can correct the start of the selection:

scrot_select_master.mp4

[hew02]

This PR would break the current behavior of being able to correct the start of the selection via keyboard and mouse, which is the most important part, in my opinion.

In other words, in the master branch you can correct the start of the selection:
scrot_select_master.mp4

Fixing that on my end, big oversight on my end, thanks. Should that functionality also be present in keyboard controls? Say holding alt will correct the start?

[daltomi]

Yes, I think it should work, that is, we'll have to test it thoroughly.

…

*hew02* left a comment (resurrecting-open-source-projects/scrot#427) <#427 (comment)> Fixing that on my end, big oversight on my end, thanks. Should that functionality also be present in keyboard controls? Say holding alt will correct the start? Message ID: ***@***.***>

[hew02]

Thank you for the feedback thus far

[daltomi]

I encountered a strange situation; if I run the command -s -K with the corresponding parameters, the crosshair cursor appears, waiting for the user to move it with the assigned keys—all good so far. But if, instead, I press the Alt key first and then the cursor movement keys, I can no longer capture the image (by pressing the spacebar).

In short:

1. scrot -s -K

2. Press Alt + up/down/etc. and release. (note how I didn't press the space bar to start the selection; I skipped that.)

3. Press the spacebar (first time)

4. Capture fails.

The solution to this behavior would be to ignore the Alt key until the first selection is made.

I'm not sure if I've explained myself clearly :-)

[hew02]

I encountered a strange situation; if I run the command -s -K with the corresponding parameters, the crosshair cursor appears, waiting for the user to move it with the assigned keys—all good so far. But if, instead, I press the Alt key first and then the cursor movement keys, I can no longer capture the image (by pressing the spacebar).

In short:

1. `scrot -s -K`

2. Press Alt + up/down/etc. and release. (note how I didn't press the space bar to start the selection; I skipped that.)

3. Press the spacebar (first time)

4. Capture fails.

The solution to this behavior would be to ignore the Alt key until the first selection is made.

I'm not sure if I've explained myself clearly :-)

Makes perfect sense and I'm going through and trying different combinations of possible inputs. Is it worth keeping the distinction between a button press and a keyboard key to start the selection? As I see it what matters is that a selection has started and some behavior should be gated until that occurs.

[daltomi]

Is it worth keeping the distinction between a button press and a keyboard key to start the selection? As I see it what matters is that a selection has started and some behavior should be gated until that occurs.

I’m not sure if I understood you correctly, but the idea is that if the user employs the --select option alone, the selection should be initiated using the mouse button.
If the -K option is also used, the selection should start by pressing the space bar.
In other words, if the -K option is used, the mouse should not trigger any selection; the cursor moves, but that is all.

Something like that.

diff --git a/src/scrot_selection.c b/src/scrot_selection.c
index 71fe6a0..d376a9e 100644
--- a/src/scrot_selection.c
+++ b/src/scrot_selection.c
@@ -226,6 +226,9 @@ static bool scrotSelectionGetUserSel(struct SelectionRect *selectionRect)
     }
 
     while (done == WAIT) {
+        if (opt.useKeyboard)
+            isButtonPressed = false;
+
         XNextEvent(disp, &ev);
         switch (ev.type) {
         case MotionNotify:
@@ -338,7 +341,7 @@ static bool scrotSelectionGetUserSel(struct SelectionRect *selectionRect)
                             scrotSelectionMotionDraw(rx, ry, p.x, p.y);
                     }
                 }
-                else {
+                else if (isButtonPressed) {
                     rx = r.x; ry = r.y;
                     scrotSelectionMotionDraw(rx, ry, ev.xkey.x, ev.xkey.y);
                 }

:-) That is just my opinion, of course; if you have other ideas, we can try them out.

[hew02]

Is it worth keeping the distinction between a button press and a keyboard key to start the selection? As I see it what matters is that a selection has started and some behavior should be gated until that occurs.

I’m not sure if I understood you correctly, but the idea is that if the user employs the --select option alone, the selection should be initiated using the mouse button. If the -K option is also used, the selection should start by pressing the space bar. In other words, if the -K option is used, the mouse should not trigger any selection; the cursor moves, but that is all.

Something like that.

diff --git a/src/scrot_selection.c b/src/scrot_selection.c
index 71fe6a0..d376a9e 100644
--- a/src/scrot_selection.c
+++ b/src/scrot_selection.c
@@ -226,6 +226,9 @@ static bool scrotSelectionGetUserSel(struct SelectionRect *selectionRect)
     }
 
     while (done == WAIT) {
+        if (opt.useKeyboard)
+            isButtonPressed = false;
+
         XNextEvent(disp, &ev);
         switch (ev.type) {
         case MotionNotify:
@@ -338,7 +341,7 @@ static bool scrotSelectionGetUserSel(struct SelectionRect *selectionRect)
                             scrotSelectionMotionDraw(rx, ry, p.x, p.y);
                     }
                 }
-                else {
+                else if (isButtonPressed) {
                     rx = r.x; ry = r.y;
                     scrotSelectionMotionDraw(rx, ry, ev.xkey.x, ev.xkey.y);
                 }

:-) That is just my opinion, of course; if you have other ideas, we can try them out.

Yes that makes sense to me, my question, if I remember correctly, is stemming from the possibility to start with mouse select and begin an area select then pressing space would start a keyboard select and create a new origin point. The opposite is true as well. My question then being should there only be on one chance to create a new origin point, either keyboard or mouse?

[hew02]

Is it worth keeping the distinction between a button press and a keyboard key to start the selection? As I see it what matters is that a selection has started and some behavior should be gated until that occurs.

I’m not sure if I understood you correctly, but the idea is that if the user employs the --select option alone, the selection should be initiated using the mouse button. If the -K option is also used, the selection should start by pressing the space bar. In other words, if the -K option is used, the mouse should not trigger any selection; the cursor moves, but that is all.
Something like that.

diff --git a/src/scrot_selection.c b/src/scrot_selection.c
index 71fe6a0..d376a9e 100644
--- a/src/scrot_selection.c
+++ b/src/scrot_selection.c
@@ -226,6 +226,9 @@ static bool scrotSelectionGetUserSel(struct SelectionRect *selectionRect)
     }
 
     while (done == WAIT) {
+        if (opt.useKeyboard)
+            isButtonPressed = false;
+
         XNextEvent(disp, &ev);
         switch (ev.type) {
         case MotionNotify:
@@ -338,7 +341,7 @@ static bool scrotSelectionGetUserSel(struct SelectionRect *selectionRect)
                             scrotSelectionMotionDraw(rx, ry, p.x, p.y);
                     }
                 }
-                else {
+                else if (isButtonPressed) {
                     rx = r.x; ry = r.y;
                     scrotSelectionMotionDraw(rx, ry, ev.xkey.x, ev.xkey.y);
                 }

:-) That is just my opinion, of course; if you have other ideas, we can try them out.

Yes that makes sense to me, my question, if I remember correctly, is stemming from the possibility to start with mouse select and begin an area select then pressing space would start a keyboard select and create a new origin point. The opposite is true as well. My question then being should there only be on one chance to create a new origin point, either keyboard or mouse?

Sorry, just reading your response again and realizing you answered my question haha!

[daltomi]

Great. Thanks. :-)
For my part, I’ve tested it, and it’s working correctly.
It’s common for more users to access the master branch, so new testers will likely appear later on.
We still need to add the Copyright notice to the following files (*.c, *.h):

git diff --name-only master

man/scrot.txt
src/options.c
src/options.h
src/scrot.c
src/scrot_selection.c
src/scrot_selection.h

@hew02 we need you to do it because it's the first collaboration, and some users prefer different names/emails.

@N-R-K , it is up to you to decide whether this PR resolves what you indicated in #369 ; if so, you can go ahead and merge it into master. Thanks :-)

[N-R-K]

@N-R-K , it is up to you to decide whether this PR resolves what you indicated in #369 ; if so, you can go ahead and merge it into master. Thanks :-)

I've only looked thru the changes at a glance. I want to go thru them more thoroughly before merging. But it'll take me some time before I'm free to do so, around a week or so.

[hew02]

Thank you guys for working through this with me. Hopefully can make more contributions further down the line :)