When using the "Capture the current pop-up only" option, Spectacle will simply disappear when using the "Take a New Screenshot" button and never show up again. It doesn't matter whether there's a pop-up to capture shown or not. Spectacle doesn't crash - the process is still there - it just won't do anything and its window stays hidden. Spectacle from git/master 249505a804c Qt 5.7.1
I noticed this too with Spectacle 17.12.1 and Qt 5.10.1. However, turning compositing off will capture something instead of getting stuck. Unfortunately it's not the area of the screen I was interested in. See also Bug 371768.
I'm seeing this with 17.08.3. Haven't yet tried turning off compositing.
*** Bug 381046 has been marked as a duplicate of this bug. ***
Confirmed on Arch Linux, spectacle 17.12.2. When compositing is off, spectacle takes an empty "screenshot" if cursor is on an pop-up (dolphin context menu, for example).
> When compositing is off, spectacle takes an empty "screenshot" That's tracked in Bug 390787.
*** This bug has been marked as a duplicate of bug 389694 ***
> *** This bug has been marked as a duplicate of bug 389694 *** Are you sure this is a duplicate? - It works fine with the compositing/KWin code path. - The other bug is about closing, here we don't even get a screenshot. - The other bug is all about notifications, nothing we have here.
> - It works fine with the compositing/KWin code path. The other way round, of course.
I was thinking that the root cause is likely the same.
Hmh, I think that's very unlikely. The issue in the other bug is that closing is delegated in a lambda to Plasma (!), and if Plasma fails to call back, Spectacle stays open forever. He we have a problem in getting an image from KWin, i.e. we are not even in the code path triggering the notification ("GUI mode").
*** Bug 401891 has been marked as a duplicate of this bug. ***
I think the cause is that Spectacle calls org.kde.kwin.Screenshot.screenshotWindowUnderCursor and waits for the screenshotCreated signal which is never send by KWin. I manually called the method and also didn't see the signal in dbus-monitor. A quick fix is using screenshotForWindow as we already grab the Id of the window under the cursor. I don't know how reliable this is compared to the old approach but I was able to get a picture of only a right click menu. diff --git a/src/PlatformBackends/X11ImageGrabber.cpp b/src/PlatformBackends/X11ImageGrabber.cpp index 4fbb89f..dc5412d 100644 --- a/src/PlatformBackends/X11ImageGrabber.cpp +++ b/src/PlatformBackends/X11ImageGrabber.cpp @@ -585,7 +585,7 @@ void X11ImageGrabber::grabWindowUnderCursor() mask |= 1 << 1; } - interface.call(QStringLiteral("screenshotWindowUnderCursor"), mask); + interface.call(QStringLiteral("screenshotForWindow"), (quint64)windowUnderCursor, mask); return; }
That works very reliably for me. Very nice find. Would you like to submit the patch, David? :)
Git commit 2ea6fc2abefd810915c38daee95fe31205ca741b by Kai Uwe Broulik. Committed on 05/03/2019 at 21:59. Pushed by broulik into branch 'Plasma/5.15'. [effects/screenshot] Set m_windowMode in screenshotWindowUnderCursor FIXED-IN: 5.15.3 Differential Revision: https://phabricator.kde.org/D19552 M +1 -0 effects/screenshot/screenshot.cpp https://commits.kde.org/kwin/2ea6fc2abefd810915c38daee95fe31205ca741b
The fix that was comitted only works for X11 - for wayland, this problem still exists.
Thanks. Can you file a new bug for that?