I've also experienced this one. I think it's related to the multimonitor setup somehow (It works as expected on the leftmost of my screens, but not on the middle one for example)

Works for me.

How many screens do you have? Are you using Wayland?

3. And no, not using Wayland.

I also have 3 monitors with Plasma on X11 and I have no issues capturing rectangles.

Thanks for the info. Does it still happen if you disconnect 2 of the screens?

3 screen setup (2x 19" & 1x 15") nvidia GPU not using wayland
it works only w/ single monitor

Operating System: EndeavourOS
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
Kernel Version: 5.10.4
OS Type: 64-bit
Processors: 8 × AMD FX(tm)-8350 Eight-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: GeForce GT 630/PCIe/SSE2

I have downgraded to spectacle-20.08.3-1

New information was added with comment 6; changing status for inspection.

yesterday I have updated to 20.12.1-1 but it still does not work w/ rectangles, in spectacle-20.12.0-1 it shows a black image in preview and in 20.12.1-1 is no longer a preview available, it does not show a preview area anymore when rectangle mode is used.

Created attachment 134890 [details]
The left half of my middle screen

Created attachment 134891 [details]
The whole middle screen (jpg for smaller size)

This seems like som kind of offset issue.

I've added 2 files, the jpg shows the whole middle screen of mine,
the png shows a selection of the *left* half of the screen,
which should show the background, but it shows the Konsole window instead!

So the content seems moved to the left, by about the amount the leftmost screens width.

Oh, and the bug only happens with the middle screen.
There is no problem with capturing a rectangle the leftmost or rightmost screen.
Only the capture of the middle screnn is "off" ;)

Created attachment 134892 [details]
The whole middle screen (jpg for smaller size)

with xrandr output

Reverting https://invent.kde.org/graphics/spectacle/-/commit/4a3cb5140cc58d73b1f0f0083d7f24f9f3a40b2a 

fixes the issue, so it's something that changed with that commit... which is a lot... :S

Found the issue:

If I add a few qDebug:

--- a/src/QuickEditor/QuickEditor.cpp
+++ b/src/QuickEditor/QuickEditor.cpp
@@ -116,8 +116,12 @@ QuickEditor::QuickEditor(const QMap<ComparableQPoint, QImage> &images, KWayland:
         input.insert(pos, QPair<qreal, QSize>(screenImage.width() / static_cast<qreal>(screen->size().width()), screenImage.size()));
     }
     const auto pointsTranslationMap = computeCoordinatesAfterScaling(input);
+    qDebug() << "pointsTranslationMap:       " << pointsTranslationMap;
+    qDebug() << "pointsTranslationMap.keys():" << pointsTranslationMap.keys();
     QPainter painter(&mPixmap);
     for (auto it = mImages.constBegin(); it != mImages.constEnd(); it ++) {
+        qDebug() << "it.key() == QPoint(1680,0) ->" << (it.key() == ComparableQPoint(QPoint(1680,0)));
+        qDebug() << "it.key():" << it.key() << "\t translated:" << pointsTranslationMap.value(it.key());
         painter.drawImage(pointsTranslationMap.value(it.key()), it.value());
     }
     painter.end();


I get:

% build/bin/spectacle
pointsTranslationMap:        QMap((QPoint(1680,0), QPoint(1680,0))(QPoint(0,195), QPoint(0,195))(QPoint(4240,0), QPoint(4240,0)))
pointsTranslationMap.keys(): (QPoint(1680,0), QPoint(0,195), QPoint(4240,0))
it.key() == QPoint(1680,0) -> true
it.key(): QPoint(1680,0)         translated: QPoint(0,0)
it.key() == QPoint(1680,0) -> false
it.key(): QPoint(0,195)          translated: QPoint(0,195)
it.key() == QPoint(1680,0) -> false
it.key(): QPoint(4240,0)         translated: QPoint(4240,0)


But it should be 

it.key(): QPoint(1680,0)         translated: QPoint(1680,0)

instad of

it.key(): QPoint(1680,0)         translated: QPoint(0,0)

I have no idea why the QMap::value() returns the defaultValue here instead of the value the key should map to...
it seems to exist correctly in the pointsTranslationMap after all...

Insertion order seems to matter:

https://invent.kde.org/brainpower/spectacle/-/snippets/1456

So question is: Is this a bug in QMap or wrong usage of QMap?

A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/48

Git commit e1fc5c40c572e3e827e2488fedae856bd8a2927d by Méven Car, on behalf of Franz Baumgärtner.
Committed on 20/01/2021 at 08:29.
Pushed by meven into branch 'master'.

fix lookup of ComparableQPoint keys in QMap

QMap::value() failed to find existing keys in some edge cases.
Which lead to problems when translating points using a QMap.

This commit improves the operator<() to fix that.

M  +1    -1    src/QuickEditor/ComparableQPoint.h

https://invent.kde.org/graphics/spectacle/commit/e1fc5c40c572e3e827e2488fedae856bd8a2927d

Git commit 2ca0ba662673928598776b65ab5d62ad00c244fd by Nate Graham, on behalf of Franz Baumgärtner.
Committed on 20/01/2021 at 17:10.
Pushed by ngraham into branch 'release/20.12'.

fix lookup of ComparableQPoint keys in QMap

QMap::value() failed to find existing keys in some edge cases.
Which lead to problems when translating points using a QMap.

This commit improves the operator<() to fix that.


(cherry picked from commit e1fc5c40c572e3e827e2488fedae856bd8a2927d)

M  +1    -1    src/QuickEditor/ComparableQPoint.h

https://invent.kde.org/graphics/spectacle/commit/2ca0ba662673928598776b65ab5d62ad00c244fd