Bug 506745 - Feature Request: Don't hide commonly used screenshot options under an extra "New screenshot" dropdown
Summary: Feature Request: Don't hide commonly used screenshot options under an extra "...
Status: CONFIRMED
Alias: None
Product: Spectacle
Classification: Applications
Component: General (other bugs)
Version First Reported In: 6.4.2
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Noah Davis
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2025-07-08 06:49 UTC by Synthetic451
Modified: 2025-09-24 18:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Synthetic451 2025-07-08 06:49:38 UTC
SUMMARY
In Spectacle's default launch mode (rectangular screenshot), there's extra friction if a user needs to choose a different screenshot mode like "Selected Window" or "Current Screen". They have to do an extra click on the "New screenshot" dropdown and then scan the dropdown menu for the option they want. On other OSes and DEs, it is usually just a single click to swap modes.

PROPOSAL
Instead of a single "New screenshot" dropdown on the bottom bar, surface "Select Window" and "Current Screen" as top-level buttons on the toolbar and then add a dropdown arrow to contain the rest of the items. So it should look like this (please excuse the poor ASCII representation of the toolbar:

Select Window | Current Screen | v

This allows the user to have easy access to the three most commonly used modes: rectangle select, window capture, and fullscreen capture, while still maintaining the other options in the dropdown arrow to the right of them.

Bonus points if the top-level options are configurable, but I can definitely understand just keeping it simple for now.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.5-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 6800U with Radeon Graphics
Memory: 32 GiB of RAM (30.7 GiB usable)
Graphics Processor: AMD Radeon Graphics
Manufacturer: HP
Product Name: HP EliteBook 845 14 inch G9 Notebook PC
Comment 1 TraceyC 2025-07-11 20:31:18 UTC
This seems reasonable to consider
Comment 2 Nate Graham 2025-08-27 17:37:45 UTC
Hmm, if we did this, we'd have to do the same for recording, which means 2 buttons on the toolbar would have to be replaced with 4. This would make the toolbar contents likely to overflow on most screens with most languages. That would require a redesign to prevent.

I'll agree that the menu-based new screenshot workflow isn't ideal here, but so far nobody has been able to come up with anything that didn't come with worse drawbacks.
Comment 3 Synthetic451 2025-09-18 16:14:02 UTC
> Hmm, if we did this, we'd have to do the same for recording

Is this necessarily the case though? Reason why I think they should be handled differently is because screen recording is usually clicking record and then spending 1 or 2 minutes before stopping, whereas screenshots frequently need to be done in rapid succession. The rapid repetitiveness of taking screenshots makes the hidden menu options significantly more cumbersome than the video recording situation. However, I do understand the need for consistency.

What if we went with an icons only approach? We're already doing that for the save and copy icons. It would be easy to represent "Select Window" and "Full screen" as icons only, and then we have the dropdown for the other options. The screen recording icons could just have a red recording dot next to them. We can even have a text label in front of them marking the two sections. So for example:

Screenshot: [Window Icon] [Monitor Icon] [Dropdown Arrow] | Recording: [Window Icon with red dot] [Monitor Icon with red dot] [Dropdown Arrow]

That way its consistent with both capture types. They're clearly labeled whether its screenshot or recording, and the two primary actions for each are revealed at the top layer. All excess options will still be available via the dropdowns.
Comment 4 Synthetic451 2025-09-18 16:19:05 UTC
That might actually give us space to add rectangle select as well, which I realize is also quite important. I don't expect this approach to be significantly larger than the current "[Icon] New screenshot" approach.
Comment 5 Nate Graham 2025-09-23 19:53:28 UTC
Probably a merge request would be the best way to make your proposal.
Comment 6 Synthetic451 2025-09-23 21:00:38 UTC
Sure, I could definitely take a stab at it! Could you point me at the right source code? Before I take a look at it, I am assuming the relevant code is here: https://invent.kde.org/plasma/spectacle

Or is the capture interface a different thing entirely, like part of Plasma or something?
Comment 7 TraceyC 2025-09-24 16:07:23 UTC
(In reply to Synthetic451 from comment #6)
> Sure, I could definitely take a stab at it! Could you point me at the right
> source code? Before I take a look at it, I am assuming the relevant code is
> here: https://invent.kde.org/plasma/spectacle

If you want to discuss the development work, please reach out in our Matrix channel for new contributors. There isn't a specific room for Spectacle.
https://community.kde.org/Get_Involved#New_Contributor?_Say_Hello_In_Matrix

 The next step is to create a merge request. In the MR, please add "Fixes: Bug 506745" so it gets linked to this report.
https://community.kde.org/Infrastructure/GitLab#Submitting_a_merge_request

Thanks for offering to help make KDE better for everyone. :)
Comment 8 Nate Graham 2025-09-24 18:26:07 UTC
Indeed! I'll give you a bit of a hint though; the code you're looking for is here: https://invent.kde.org/plasma/spectacle/-/blob/master/src/Gui/CaptureOverlay.qml?ref_type=heads#L434