Created attachment 158311 [details] Example I updated to Kde Gear 23.04 yesterday and I really like the new spectacle, but I noticed a problem: when I take a screenshot with the rectangular region and capture an area of the screen near the bottom of the screen, the annotations go below the screen Operating System: Arch Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: X11
Cannot reproduce with a single screen; the toolbars switch positions and move to be above the region, rather than below it. Can reproduce with a dual-screen setup where the screens don't share a baseline.
*** Bug 479212 has been marked as a duplicate of this bug. ***
*** Bug 472151 has been marked as a duplicate of this bug. ***
This bug currently affects my current setup where both monitors don't share a baseline. I've included a video and screenshots on my KDE Forum post: https://discuss.kde.org/t/unexpected-capture-rectangular-region-behaviour-near-the-bottom-of-the-screen
(In reply to contact from comment #4) > I've included a video and screenshots on my KDE Forum post: Thanks for that! I have been on the CC list for this bug, but just read in that thread that it is good to post if you have the problem, so I'm posting. I have a 1080p and a 1440p monitor, and whether they share the same upper or lower coordinates (so, even with the same baseline), I still see this bug. It appears to be that spectacle is selecting a toolbar position based on the desktop geometry rather than the display geometry, and consequently selects a location which is visible to the desktop but not the display.
Apologies, I neglected to mention - I hope maybe it might help the devs to know that I see similar bugs elsewhere in KDE, for example in Kate's Recent Documents list (if you let it be long enough, it draws off-screen, but on-desktop). I've not had the opportunity to file any of these but I thought it might help track things down, if I mention that I don't see this exclusively in Spectacle. This may just be a coincidence, or maybe there's shared code, I can't say. Just letting you know :)
My bad, I *do* have that Kate bug logged: https://bugs.kde.org/show_bug.cgi?id=485770 I can't be certain it's directly related, but... they sure act the same. Firefox's 'All Tabs List' does this, too, but since it's not a KDE app I'm less inclined to draw a parallel... stranger things have happened, though.
This not only applies to the baseline but also the vertical bounds (e.g. small laptop display at the bottom and a larger display above it)
This is still happening on KDE 6.2/Spectacle 24.08.2 (on Arch). I have 3 QHD screens side by side, one of them in portrait/vertical rotation. The controls are always placed correctly on the vertical monitor, on the other monitors they are placed of screen if my selection box reaches the lower-edge of the screen.
Created attachment 178374 [details] An annotated multi-monitor setup in which the bug presents I've attached an image showing an example of a multi-monitor setup in which the bug is possible, annotated with an example selection area exhibiting the bug.
Created attachment 178431 [details] The toolbar only changes position on the right screen, when the rectangular area is dragged to the bottom of the screen. On the other displays, taking screenshots of the bottom part is impossible. I have the same issue on Plasma 6.3 on Fedora 41. I can only take a screenshot of the bottom of the screen on the right-most screen in my attachment. On all other displays, the toolbar becomes unusable, when the rectangular region is dragged to the bottom of the screen.
Created attachment 178432 [details] Spectacle tooltip bug I can confirm this on Plasma 6.3 Spectacle should only take current monitor into account instead of whole display space.
I can confirm this behavior after moving to KDE neon 6.2 with Plasma 6.3.0 and Wayland I had to move from Flameshot to Spectacular.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/443
Git commit 46378cd6f7f754fff87cd51bc7e724349014b66c by Noah Davis. Committed on 27/02/2025 at 16:44. Pushed by ndavis into branch 'master'. Allow dragging rectangle mode toolbars when selection isn't actively changing Not really a fix for the issue where toolbars can go out of bounds when the screens region is concave, but should make it easier to actually use the toolbars in that situation. M +1 -3 src/Gui/ImageCaptureOverlay.qml https://invent.kde.org/graphics/spectacle/-/commit/46378cd6f7f754fff87cd51bc7e724349014b66c
can confirm with a monitor setup in an "L" shape where the side monitor is taller than the center monitor.... there is "unused" screen real estate above the center monitor you can only capture by taking a full destop image but windows in that part of the "screen" cannot be seen. i don't think it's a bug, as much as it's just a limitation forcing every multi monitor setup into a rectangular box, some of which you can't see.
That is the behaviour I described in comment 5: > based on the desktop geometry rather than the display geometry, and consequently selects a location which is visible to the desktop but not the display. For an example of this same bug in a different app, change kate's setting, "Maximum number of entries in recent file list" to something big enough to not fit on screen (and also, open enough files to fill it up). When you do this, normally, the menu will be restricted to the size of your display, with scroll buttons on the ends. Except, it will be broken for desktops like ours, and the scroll button won't appear as required, instead the menu will roll off into that inaccessible invisible area of desktop which is not on any display. If you do this on the tallest of your displays, it will work as expected and you'll see the scroll buttons on each end. If you have offset displays, it will only show the scroll buttons on the top of the highest displays and the bottom of the lowest. ie, it doesn't make the menus fit on screen, it makes the menus fit on *desktop*. I'd say it's pretty clearly a bug, when a menu which is intended to be seen and clicked on, can't be seen or clicked on :D
This unfortunately still happens with the new Spectacle 6.4.0 UI. System information: Linux/KDE Plasma: Fedora Linux 42 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1
*** Bug 469668 has been marked as a duplicate of this bug. ***
*** Bug 469513 has been marked as a duplicate of this bug. ***
*** Bug 487870 has been marked as a duplicate of this bug. ***
*** Bug 486165 has been marked as a duplicate of this bug. ***
I have the same issue when dragging a rectangular bounding box. 1920x1080 monitor on left and centered vertically to a 2560x1440 monitor on the right. Spectacle: v6.5.1 DE: KDE Plasma v6.5.1, Wayland OS: Arch Linux, Kernel v6.12.56-1-lts
Should be fixed by: https://invent.kde.org/plasma/spectacle/-/merge_requests/498
(In reply to tomashnyk from comment #25) > Should be fixed by: > https://invent.kde.org/plasma/spectacle/-/merge_requests/498 Looks like not quite, but we're trying! Probably just needs someone to confirm the suggestion works, and if so, merge it. If nobody else can do it first, I'll do the confirmation of the patch as soon as I'm able. I have an outage standing in my way at the moment but hopefully it won't be long.
Mario crushed it with https://invent.kde.org/plasma/spectacle/-/merge_requests/500
*almost crushed it. isn't there a way to keep either of the menus from obscuring the selected area? Why can't they be stacked above or below the area rather than have one of them in the way of what you are trying to capture (and possibly annotate behind the annotations menu)? my current plasma 5 version will place both menus outside of the rectangular zone and either stack them above or below or place one above and one below depending on the room... the only problem with mine is that it doesn't respect screen boundries, only the desktop boundary.
(In reply to goo from comment #28) > *almost crushed it. * crushed it I meant what I said, your correction is incorrect. A reminder that this bug has been annoying us for several years now, and this patch kindly provided by Mario DOES fix it. > isn't there a way to keep either of the menus from obscuring the selected area? Theoretically yes but it's not nearly as simple as you make out. Think about the various permutations involved here. If you've having trouble imagining some, just look at these two MRs. I do agree with you that it's annoying when the toolbar obscures the thing I'm using it for, but what you have there is a feature request threatening to bikeshed this fix. > the only problem with mine is that it doesn't respect screen boundries, only the desktop boundary. That is the bug we're here to fix and Mario did. Let's show some love.
fair enough, i'll make a new bug report when the time comes.... hopefully mario will still be fresh enough on it to see the solution.
(In reply to goo from comment #30) > fair enough, i'll make a new bug report when the time comes.... hopefully mario will still be fresh enough on it to see the solution. Please do link it here, I imagine that most of us share your thoughts on this. Maybe we can pitch in when the time comes.
Fixed by https://invent.kde.org/plasma/spectacle/-/merge_requests/500
(In reply to goo from comment #28) > *almost crushed it. > > isn't there a way to keep either of the menus from obscuring the selected > area? Why can't they be stacked above or below the area rather than have one > of them in the way of what you are trying to capture (and possibly annotate > behind the annotations menu)? > > my current plasma 5 version will place both menus outside of the rectangular > zone and either stack them above or below or place one above and one below > depending on the room... the only problem with mine is that it doesn't > respect screen boundries, only the desktop boundary. I agree that would be more convenient, and I’d be interested to see exactly how Plasma 5 handled it. In theory, it should be possible to dynamically reposition the toolbars based on the screen layout and the selected area, but we would need a solid plan for how to handle this gracefully. There are just some edge cases where I can't currently picture a good solution: A) The selection covers the entire screen -> Should the toolbars overlap the content, or appear on another screen? What if the selection covers multiple/all screens? B) There is only space on the left/right side -> Should they move there? I'm not a UI designer, but I worry that having toolbars appear in seemingly random locations depending on the context might be confusing. BTW: You can actually drag and drop the toolbars to move them out of the way. Obviously not the most elegant solution, but as a non-power user myself, I find it quite workable.
(In reply to Mario Roß from comment #33) > I agree that would be more convenient, and I’d be interested to see exactly > how Plasma 5 handled it. on my plasma 5 both tool bars act as a group and are either above or below the selected area unless there is no room in either location for the group and then both overlap the selected area.. > A) The selection covers the entire screen -> Should the toolbars overlap the > content yes, in that case they should overlap the selected area. > B) There is only space on the left/right side -> Should they move there? no, they are better either above or below the selection, however, if there is room for at least ONE of them to be outside the selected area, then i would prefer that over keeping them together as a group and overlapping. > BTW: You can actually drag and drop the toolbars to move them out of the > way. that's a game changer... i cannot drag my plasma 5 menus and did not know about this feature.