`flameshot gui` mirrors screen on-screen when invoked

[shawnyeager]

Flameshot Version

Flameshot v12.1.0 (-) Compiled with Qt 5.15.14 via Arch AUR

Installation Type

User repository (AUR)

Operating System type and version

Arch

Description

This began over the past few days. As Arch is a rolling release, I can't pin it down, whether a recent build of mutter or a component of Gnome.

See screenshot.

Steps to reproduce

1. Invoke flameshot gui via Gnome keyboard shortcut
2. Observe that screen has been duplicated on-screen at ~80% scale
3. Otherwise, functions normally

Screenshots or screen recordings

System Information

OS: Arch (rolling, current) Linux framework 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64 GNU/Linux

Display: Framework 13" 2.8k

Desktop Environment: Gnome 47.4 @ 175% fractional scaling

[shawnyeager]

Update: I just tested this on an external display @ 100% (no fractional scaling), and the behavior is normal/as expected. So, given that fractional scaling is experimental, maybe this a non-issue for now.

[mmahmoudian]

Yes, this is already reported and is an known issue that fractional scaling would break how Flameshot displays the captured screen. Perhaps Gnome is new to the game as KDE have had this issue for quite some time already.

This is not intuitive to fix when considering multi-monitor setup with various scaling factors in arbitrary arrangements. This is how Flameshot works:

1. When triggered, it requests a screenshot from the compositor
2. It tries to have a fullscreen borderless opaque window above everything else
3. Load the annotation tools and etc.

Now, when we have a multi-monitor setup with various scaling factors, we are practically left with one choice as far as I can think of: open a borderless fullscreen window on every monitor and show the content in accordance to the monitors' specifications. In X11 that's not a big deal, but in Wayland that's a bit of an issue. Now, to all this mess, add the situation that the user wants to crop a part that is shared across two of the monitors. Not only should we sync the position of the selection area between two or more Flameshot windows, but we have to later combine the resulting images from all the Flameshot windows, scale them to be on the same level of scale, and attach them together with a perfect alignment to result in a clean uniform image. And to add to all this complexity, add the way Gnome is treating other developers and how much of an access the Gnome public API has compared to their private API.

Anyways, this is a duplicate issue, and should be closed in favor of the earlier one. I will keep this open until I get behind a computer and can find that issue number.

Thanks again for reporting this. It is good that our users are willing to help and point out issues.

[Lorak-mmk]

This is not intuitive to fix when considering multi-monitor setup with various scaling factors in arbitrary arrangements. This is how Flameshot works:

@mmahmoudian As you explained, handling multiple monitors with various scaling factors is extremely hard.

99.9% of the screenshots I take are of some part of a single display, even if multiple displays are connected - I suspect it is the same for many (most?) other people. For that use case, it would be enough to have an option for flameshot gui to limit it to the display that the cursor is on, instead of all the displays simultaneously. Intuition tells me adding such option should be much simpler than handling arbitrary multi-display setups, but I don't know the codebase of flameshot at all, so it may be totally wrong. WDYT?

[mmahmoudian]

@borgmanJeremy do you think handling the fractional scaling is easier or adding a new CLI to the gui subcommand to make flameshot gui monitor-specific (based on the comment above by @Lorak-mmk )? Tbh I have no clue if we are going to handle fractional scaling ourselves or the Qt/compositors are capable of handling that and we just need to delegate it to them.

[borgmanJeremy]

@mmahmoudian I've been thinking about this for a while now in a couple of different ways. I actually think the most consistent thing to do would be to adjust how flameshot gui works. Rather than attempt to draw one canvas across all monitors, the gui command would first prompt the user to click on which screen should be captured. Then the main capture widget would only be drawn on that screen.

The screen selection step should be skipped on MacOS because this already the default behavior on Mac, only the screen where the tray command was invoked will be used.

I have a sneaking suspicion that on some Wayland DE's that even if Monitor 2 is selected, and properly captured, the full screen widget would still be present on Monitor 1. This is because on many Wayland DE's, the Qt framework can only suggest window positions to the DE, not force the move.

[mmahmoudian]

@borgmanJeremy

first prompt the user to click on which screen should be captured. Then the main capture widget would only be drawn on that screen.

Sounds like a plan, and somewhat in-line with the suggestion by @Lorak-mmk . I also remember that a similar thing was discussed in another issue to only "occupy" one monitor and leave the others free for the user.

I'm not against the idea, and I think we can handle the upset users and guide them to the new behavior. I'm sure that soon people would say that they always screenshot from their monitor X and they will request a way to choose the monitor in CLI or config. So maybe we should consider that and accomodate for that when we implement this?

As a side observation, I've realized that many software are struggling with the monitor selection. For instance my favorite terminal, yakuake which is C++ and Qt by KDE folks, has a config to only spawn in a particular monitor, but after easy restart, the monitor orders are shuffled and I have to change the settings after each reboot. This is something that perhaps should be fixed upstream (either Qt or Plasma), but users would see it as a problem of the yakuake rather than Plasma/Qt.

As for some DEs, let's for now mainly focus on major DEs. Smaller DEs and WMs can hopefully implement that option as well.

[thinkgos]

Update: I just tested this on an external display @ 100% (no fractional scaling), and the behavior is normal/as expected. So, given that fractional scaling is experimental, maybe this a non-issue for now.

Good, Solved my problem!