Selector doesn't drag corner past opposite corner

[DarthGandalf]

It just pushes the whole selected rectangle (which is now a single line or even a point) further

[carygravel]

On a bionic-based system, it is working for me, without my having done anything to fix it, as is the Gscan2pdf::ImageView version. I'll test my Debian testing based system next.

[DarthGandalf]

It was you who noticed the issue at all. What system that was on?

But I confirm this behavior on Gentoo

[carygravel]

Just committed a fix for this.

[carygravel]

Is it time for a new release?

Or is there something you'd like to get in in the next couple of days?

[DarthGandalf]

Tip: you could use "Closes #1" in commit message to close the issue automatically, and that would also link the commit here.

Sure, let's release. I wanted to do it some time ~soon anyway, to get #16 in.

[DarthGandalf]

https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword has list of keywords it understands

[DarthGandalf]

You forgot to push the master branch with v6

[carygravel]

You're right that Github hadn't registered it, but I did push it, with git push --tags, which on other repo pushes the commits, plus the tags. Github seems to need to have the commits first, and the tags afterwards in a second operation.

[DarthGandalf]

I think this is not specific to Github, but because of git push --tags. git push --tags master would push both in a single operation.
Also, from man git-push:

When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the simple value for push.default

Probably that's why it worked for you with 2 commands git push --tags; git push without explicitly mentioning master.