Bug: selection does not work without a compositor (regression)

[benaryorg]

Originally reported in #201 I wanted to open this as an actual issue since it is a regression.
I used to run gscreenshot 3.5.0 on awesomewm without a compositor because I simply don't need a compositor.
However now that my distro had a version bump I'm on 3.6.3 which presumably added the overlay with transparency and has no option to disable that (read: to behave like 3.5.0).
This means that somewhere between 3.5.0 and 3.6.3 there was a change that broke gscreenshot's selection mode for all users without a compositor.

It would be enough to add a CLI option to disable the transparent overlay (and instead just have the selection borders, as previously), though ideally there would be a way for this to be detected at runtime and enable the new transparency feature only when support is available.

I'm fine if support for setups without a compositor is out of scope for gscreenshot but honestly I don't want to go looking for a screenshot tool that actually works again.
The old ones (looking at scrot) have visual glitches all over the place, or sometimes just don't work, and others require a constantly running background process or something like that.
It's getting really hard to find a tool that just "lets me take a screenshot of a selection of my screen by spawning a process on the most simple and basic desktop setup imaginable", which was what gscreenshot did for me for about a year now.

[thenaterhood]

What I've been kicking around is making the selection area colors fully configurable because that's an accessibility problem aside from compositor settings, if someone needs higher contrast or is otherwise using a color scheme where it's hard to see the edge of the selection area. I guess I could just add it as a CLI option, would be a pretty easy change. Sometimes "good enough" is, well, good enough.

…

On Thu, Nov 28, 2024, at 6:31 PM, Katze wrote: Originally reported in #201 <#201> I wanted to open this as an actual issue since it is a regression. I used to run gscreenshot 3.5.0 on awesomewm without a compositor because I simply don't need a compositor. However now that my distro had a version bump I'm on 3.6.3 which presumably added the overlay with transparency and has *no option to disable that* (read: to behave like 3.5.0). This means that somewhere between 3.5.0 and 3.6.3 there was a change that broke gscreenshot's selection mode for all users without a compositor. It would be enough to add a CLI option to disable the transparent overlay (and instead just have the selection borders, as previously), though ideally there would be a way for this to be detected at runtime and enable the new transparency feature only when support is available. I'm fine if support for setups without a compositor is out of scope for gscreenshot but honestly I don't want to go looking for a screenshot tool that actually works *again*. The old ones (looking at scrot) have visual glitches all over the place, or sometimes just don't work, and others require a constantly running background process or something like that. It's getting really hard to find a tool that just "lets me take a screenshot of a selection of my screen by spawning a process on the most simple and basic desktop setup imaginable", which was what gscreenshot did for me for about a year now. — Reply to this email directly, view it on GitHub <#212>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATXBREOMEWLVDCH5VJD6S32C6RVHAVCNFSM6AAAAABSWADAOOVHI2DSMVQWIX3LMV43ASLTON2WKOZSG4YDGNBYGQYTSMA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[thenaterhood]

I have a change slated for the next release of gscreenshot that adds a "--select-color" command line parameter which takes an RGB or RGBA hexadecimal string for the region selection highlighting. It's available on the "dev" branch currently if you want to check it out before the next release.

gscreenshot --select-color="#ffcccc"

[benaryorg]

I just tried commit e3ef8df and unless I messed up (and I don't think I did, otherwise I wouldn't see --selct-color in the help output) the issue still persists.
There are two issues with the colour selection; running gscreenshot -s "--select-color=#000000" does not apply the colour for the selection at first (it's still the same grey rectangle) until I hit Escape which opens the GTK window and as soon as I start a selection clip from there the colour applies.
The same happens when using gscreenshot-cli, except that using Escape on that one just exits the entire process, so it's just the initial colour being off (and non-transparent, see below).
However the colour is still used without any transparency meaning that trying to select a section of a window is basically impossible because as soon as I hover over the window the entire window turns into a solid colour (so I can't see where to start the selection).
I also tried other colours and even using #00000000 as a colour (which I thought might set an alpha channel) to no avail.

[benaryorg]

If you want I can probably build you an ISO with a bare-bones setup that exhibits the issue in a qemu VM where you'd expose your local git checkout using virtfs so you can keep editing on your regular machine and only click a desktop icon in the VM to rebuild or something like that.
Since I'm using NixOS which is notoriously different from other distros the workflow for getting the dev setup going may be a bit of a hurdle otherwise, and writing a little script for building and running the virtfs mounted directory shouldn't be too hard and gives you a way to directly test changes.

[thenaterhood]

Do another pull and see if it works better now. I was expanding the test suite and found a spot where the color wasn't getting passed correctly.

I also made it so passing an empty string gscreenshot --select=color='' will disable color modifications entirely and just use the defaults of the underlying region selection tool, which might work better in some situations.

There's also a new --select-border-weight option to adjust the border thickness of the selection border which might make it easier to see the boundaries of the box in some setups.

[benaryorg]

Edit: tested with 5cde322

Okay, so now the behaviour of the colour is consistent across the GUI, CLI, and specificaly the gscreenshot-cli invocation, all of them use the provided colour.

However:

• gscreenshot-cli -s: still the same solid grey, except now it is over-extending over the window which I'm hovering over (by the default border weight I imagine)
• gscreenshot-cli -s --select-border-weight=0: solid grey, still over-extends slightly (meaning if I take a screenshot of a maximized window I still get a few pixels of taskbar captured; that is, I get both the window border as well as additional pixels beyond that, which is bad)
• gscreenshot-cli -s --select-border-weight=0 "--select-color=#000000": solid black, still over-extends; this only shows my window manager's window border which is a single pixel so I can't really see that much when selecting a window (also an issue for window managers that are configured to not draw a border), but it's good for selecting a rectangle
• gscreenshot-cli -s --select-border-weight=0 "--select-color=#00000000": same as above
• gscreenshot-cli -s --select-border-weight=0 "--select-color=#000000ff": same as above
• gscreenshot-cli -s --select-border-weight=1 "--select-color=": fully transparent, still over-extends, no perceptible border; same as above actually, I assume my window manager's border is placed directly on top of the 1px wide window frame
• gscreenshot-cli -s --select-border-weight=1 "--select-color=": fully transparent, still over-extends, perceptible border; same as above actually except now the border seems two pixels wide, I somehow suspect that the default colour is the same as my border colour, this works nicely IMHO
• gscreenshot-cli -s --select-border-weight=-1 "--select-color=": same old solid grey, does not seem to over-extend visually though, however still over-extends on the resulting screenshot by a few pixels

Also I just noticed that when running gscreenshot-cli -s and hitting Escape, it does print "Selection was cancelled" as expected followed by a newline and then the name of the file it stored the screenshot to, so while it says it cancels, it doesn't actually cancel somehow.
Since I just noticed; "Selection was cancelled" should most likely be printed on stderr, not stdout, otherwise this will most likely cause issues when used in scripts or something (maybe also exit with a non-zero status code?).

The over-extending of the screenshot area when selecting a window is a rather big problem in my opinion since it presents a potential information leak (i.e. sharing window A still includes pixels of window B which may be sensitive in some way).
Since now we're talking pixel offsets I should probably mention that I'm running at 1440p.
Other than showing additional windows, it also means that when I take a screenshot of my maximized window that has a geometry of 2558×1418 (i.e. 2560×1440 but with the taskbar on top cutting off some of the height and the 1px border cutting off 1px on every side) I get a screenshot of size 2562×1422, meaning it not only includes the border (which'd be fine-ish I guess), but also adds a black pixel on the left, right, and bottom since those are outside the screen, and it adds a pixel of my taskbar.
My guess would be you've added the border instead of subtracted it (or subtracted a negative value instead of added it)?
Note that this happens with 3.6.3 already, which means I should probably split that off into a different issue, if there isn't one already.?

I also think that when taking a screenshot of a specific window (i.e. when hovering over windows in the -s mode) it'd be a good thing to have the border extend inwards from the window.
After all as a user in that situation I'm not interested in what exactly is visible since I know it to be the window content, rather I'm interested in seeing the exact window, and with e.g. a full-screened window the border is not visible at all.

[thenaterhood]

gscreenshot-cli -s --select-border-weight=1 "--select-color=": fully transparent, still over-extends, perceptible border; same as above actually except now the border seems two pixels wide, I somehow suspect that the default colour is the same as my border colour, this works nicely IMHO

Good to hear!

The border offsets are actually really interesting. gscreenshot doesn't do that natively, it's using slop (X11) or slurp (Wayland), which then return the screen region which gscreenshot uses directly. With some experimentation and knowing the border width the regions are just numbers so it wouldn't be that hard to calculate an offset to make them behave a little more consistently. It's also entirely possible that there's a bug in those tools themselves.