flameshot icon indicating copy to clipboard operation
flameshot copied to clipboard

Flameshot no longer respecting number argument for screen verb

Open HMassey opened this issue 6 months ago • 4 comments

Flameshot Version

Flameshot v12.1.0 (88c738ff) Compiled with Qt 5.15.17

Installation Type

Compiled from source

Operating System type and version

Arch linux 6.14.7

Description

Mentioned at the end of #2522

If I take a screenshot with the number argument, it only ever takes a screenshot of the screen my mouse is on.

Image

Image

(This one I moved my mouse off with a delay, but used --number 0 which typically is the larger screen)

Image

I believe this is in code since the last release, or the Qt version perhaps, because if I use the old flameshot release (note the lack of ./ in the command)

Image

It respects the screen (or at the very least, it changes), it just has the bug on #2522

Image

@mmahmoudian You said to tag you! Honestly, I wanted to try and look into this myself, but I think I might need to do some fundamentals in C++ first 😅

Steps to reproduce

  1. Have two screens!
  2. Run flameshot screen --number 0
  3. Observe produced screenshot
  4. run flameshot screen --number 1
  5. Observe produced screenshot is identical
  6. Run flameshot screen --number 0 -d 3000 and move your mouse to your other monitor within 3 seconds
  7. Observe produced screenshot is different

Screenshots or screen recordings

No response

System Information

Arch linux 6.14.7 1080p + 1440p both in landscape, Arandr is open on the first screenshot for a config. My WM is i3, I'm using xorg.

HMassey avatar Jun 02 '25 21:06 HMassey

Thanks dor tagging me and opening the issue with enough details. This is unlikely to be a Qt issue. @borgmanJeremy and a contributor are working on qt6_2025 branch on that, so we have not yet migrated to Qt6.

This looks like a regression. I will try to reproduce this on my multi-monitor setup and see if I can reproduce it.

mmahmoudian avatar Jun 03 '25 06:06 mmahmoudian

I just tried it on KDE Plasma Wayland on Arch with same exact Flameshot version ( 88c738ff ) and the --number argument for screen subcommand works normal and as expected. Unfortunately I don't have Xorg on this particular computer, so I cannot test it.

Is it possible that you have some special settings in your i3wm that is causing this?

mmahmoudian avatar Jun 03 '25 07:06 mmahmoudian

I shouldn't have anything pertaining to monitors in my i3 config, but I am on xorg which may make things behave differently. I have KDE Wayland and KDE xorg so when I finish work I'll swap DE and try both.

HMassey avatar Jun 03 '25 10:06 HMassey

I have tested on KDE x11 and KDE Wayland and both are working. Interestingly, on the x11 session by moving the configuration of the displays around, I could cause this:

Image

That black area couldn't even be right clicked and reminded me of the original bug in terms of offset screen geometry. But even with the black space there, the number argument worked fine. I don't know what this means really but I found it interesting 😂

I tried to disable focus following the mouse on i3 but that didn't fix it (I was thinking it was maybe somehow stealing focus back) but I otherwise have a very normal config. I can post it if you're familiar with the i3 ecosystem but I'm fairly confident it's not that relevant, given that the old release of flameshot does change screen (erroneously).

I don't know what you would like to do with this considering the above, it's only affecting me on i3 and I personally can totally live without this functionality, I just thought it was a wider issue needing reporting and didn't think to check a different DE (since I thought it was a lower level thing).

Let me know if you want me to add/test anything

HMassey avatar Jun 03 '25 21:06 HMassey

To add to this, I am running into this problem using flameshot screen even after the fixes introduced by #4127. I get different results based on whether I use the --number parameter or not, as it seems to be offset based on which monitor the cursor is on regardless of which monitor is specified, but what gets captured (or blackness) is affected by it.

Flameshot v13.1.0 ()
Compiled with Qt 6.9.1
linux: 6.15.10-200.fc42.x86_64
fedora: 42

Reproduced using a10562f, installed F42 RPM from latest build.

System configuration:

Kernel: Linux 6.15.10-200.fc42.x86_64
DE: KDE Plasma 6.4.4
WM: KWin (X11)
GPU: AMD Radeon RX 9070 XT

$ xrandr --listmonitors
Monitors: 3
 0: +*DisplayPort-0 1920/521x1080/293+1920+0  DisplayPort-0
 1: +DisplayPort-1 1920/521x1080/293+3840+0  DisplayPort-1
 2: +DisplayPort-2 1920/521x1080/293+0+0  DisplayPort-2
Image

Actual screen layout: Image

Screenshot taken using flameshot screen -c while cursor is on center screen: Image

Screenshot taken using flameshot screen -c while cursor is on right screen: Image

Screenshot taken with flameshot screen --number 1 -c while cursor is on the left screen: Image

Screenshot taken with flameshot screen --number 1 -c while cursor is on the center screen (also black sometimes): Image

This has the same sort of symptoms as #4015, so while region capture and fullscreen capture are fixed by #4127, specific screen capture is not. cc: @ionsquare

pointydev avatar Aug 24 '25 04:08 pointydev