Created attachment 111501 [details]
From the keyboard shortcut + enter

Created attachment 111502 [details]
From the keyboard + double click

I also mention that invoking the rectangular screenshot from the panel shorcut and from the menu/krunner has the screenshot not autosave and also not show the cursor, but the keyboard shortcut autosaves the image and shows the cursor if it is in the area that is screenshoted which obviously happens if you double click in said area.

> From the keyboard shortcut + enter
> [image w/o cursor]

> From the keyboard + double click
>[image w/ cursor]
I assume in both cases you mean "Shift+Meta+Print" for the shortcut? I cannot reproduce with Spectacle 17.12.3, for both cases I see the cursor, but your screenshots show otherwise. The method used to start capturing might make a difference, but I doubt pressing Enter or double clicking will influence whether the cursor is shown. Could you double-check that?

---

Apart from this, I suspect the issue is that in DBus mode the GUI settings are not respected. We'd have to investigate whether that's a bug or a feature, as in some modes there are switches to override certain GUI settings.

> the keyboard shortcut autosaves the image
That's correct: The global shortcut will only show a notification, but not the complete Spectacle GUI.

Confirmed on Arch Linux, spectable 18.04 when I use meta+shift+print to take the screenshot. Use enter or double click makes no difference.

Dr. Chapatin: I appreciate your bug reports, but as I mentioned before, adding "Confirmed on…" adds absolutely no value, on the contrary, it adds noise to my and other's inboxes, preventing us from actually fixing things.

If the bug is still open and reproducible, obviously it has not been fixed yet. Only if the bug is open and not reproducible anymore it might be worth adding a comment to that effect.

From https://stackoverflow.com/a/51664338:

If you press the hotkey, a D-Bus command is invoked [...]
  qdbus org.kde.Spectacle / org.kde.Spectacle.RectangularRegion true

The argument for this RectangularRegion method indicates the value for includeMousePointer

https://bugs.kde.org/show_bug.cgi?id=397113#c1
> Do you request the default [for the shortcut] to be changed?
IMO it makes sense to follow the setting in the GUI, everything else is just confusing to the user. However, we should probably still provide a DBus option to explicitly specify the behaviour.

> Or a secondary hotkey with the different behaviour?
I think we already have too many shortcuts, and it would be difficult to communicate to the user what the difference between all those options is.

As for implementing a fix: Is there a way to set default parameters for arguments of DBus calls? If not, perhaps it would make sense to only have a single string parameter, which would allow to specify all options?

*** Bug 397113 has been marked as a duplicate of this bug. ***

The solution "having two shortcuts" is nice.

And having the text "Take rectangular region (with mouse pointer)" and "Take rectangular region (no mouse pointer)" being "Take rectangular region" is explicit. Users go in the settings Once to choose their preference.

If a shortcut depends on the state of Spectacle, people must then know that the Shortcut in section "KDaemon" is actually related to a program called "Spectacle".

And for this example, me, I went to the shortcuts settings,and I chose to have just one print screen shortcut "print screen means rectangular region without mouse". And if I want a special case once in a while, I open Spectacle. Or I go in the settings and add a new shortcut like Meta+PrintScreen.

If we have too many shortcuts, why not create a section called "Spectacle" in the left side menu? Currently the screenshots shortcuts are in "KDaemon". A regular user wouldn't even know what that means. The left menu has a section called "Amarok" so why don't we have a section called "Spectacle" or "Screenshots".

Having a long list is a feature I like in KDE, you can choose global shortcuts based on your needs.

And having a ways to add DBus parameter from the interface is nice too. I'm think about a button "duplicate shortcut", then one can modify the shortcut and the parameter. However the interface shall remain as simple as now.

In kate, that would be awesome. A user can take the "Join lines" shortcut, duplicate it, modify the new one to have "Join line with commas", the first parameter of Join being " " by default. When duplicating the shortcut, it would change it to ", ".

The "join lines" shortcut would be discretely marked as "having parameters".

I'm mentioning it here because that's about generally keyboard assignement in all kde apps. A feature I like in KDE is that all their apps have the same keyboard shortcuts menu.

> If we have too many shortcuts, why not create a section
> called "Spectacle" in the left side menu?
Creating a new section won't solve the issues having too many shortcuts results in:
- This is not only about "Rectangular region", but would have to be added to every other type too (doubling the number of shortcuts).
- We have an in-progress patch for adding copying to the clipboard (doubling the number of shortcuts again).
- There are many other options, each increasing the number of shortcuts.
- Are there even enough modifier keys on a keyboard to create a shortcut scheme people can actually remember and which would not conflict with other global shortcuts?

I'm not saying we should prevent people from adding specialized shortcuts by themselves, I'm just against shipping all of them by default.

As for your other comments, I'm afraid they are a bit off-topic for this particular bug (we prefer to handle only a single topic per bug to keep things manageable, I hope you understand).

I agree the keyboard has not soo much keys but here we're speaking about adding "entries to the shortcuts list", currently we have tons of shortcuts that don't have a default shortcut, and that's a good thing, because people can choose theirs.

I agree the exponential blowup is an issue, the most useful parameters should be the default, like TakeRectangular(mousePointer=true). Then we can add a few others like TakeRectangular (mousePointer=false) and if later we implement a new feature like "toClipboard=true" we wouldn't add aaaall the possibile combinaison. For example the list would be:

mousePointer=false (Take Rectangular)
mousePointer=true (Take Rectangular with mouse)
mousePointer=false, toClipboard=true (Take Rectangular to clipboard)

The case (mousePointer=true, toClipboard=true) is not in the list because it was considered "rarely useful".

That's why I think having a way to duplicate a shortcut and add parameters is nice. I'll open two tickets on general KDE for that.

And if the functionality is useful, we should add default shortcut for all KDE users. But to be honest, the only one that's worth having is PrintScreen being "take screenshot and launch spectacle", no need for Shift+PrintScreen or Meta+PrintScreen for average user, they can go in the settings to config that. The idea is that when pressing PrintScreen, the user is prompt to.

For This ticket, I'd say "No, don't look at spectacle settings for shortcut".

I'll open a ticket "Add Screenshot category in general shortcut" where the entries would be moved from KDaemon to Spectacle (next to Amarok).

I'll open a ticket on general kde for the ideas of duplicate a shortcut and add string parameters.

Is there another way to talk about new features of KDE other than this "bugs" site?

> I'd say "No, don't look at spectacle settings for shortcut".
Hm, that's not really what I envision. Let's wait what others have to say on that topic.

> the only one that's worth having is PrintScreen
TBH, I find the current selection of shortcuts keeps a good balance between offering too few and too many options.

> Is there another way to talk about new features of KDE other
> than this "bugs" site?
Contributors can also use tasks on the workboards and mailing lists. If you are a user, there is the forum for "talking" and Bugzilla (for wishes). There's IRC too.

> I'll open a ticket "Add Screenshot category in general shortcut" where the entries would be moved from KDaemon to Spectacle (next to Amarok).

The categories you see for shortcuts are the names of the _running_ applications that handle them. Since you would expect that Spectacle reacts to hotkeys even if it is not running, these have to be handled by a separate daemon.

Created attachment 114286 [details]
Subcategories

What about creating subcategories in KWin ? Currently it only has One category called.. hm... KDE Daemon (see attachement).

We could organise the shortcuts if we have too many.

Okay, actually the PrintSceren shorcuts are not in KDE Daemon, but in "Module de configuation du système". That's even more confusing. I would never expect a "Screenshot|Spectacle" shorcut to be there.

There are two locations to configure shortcuts for Spectacle:

- The "Custom Shortcuts" KCM (aka KHotKeys), section "Screenshots", which shows 4 shortcuts. This seems to match spectacle.git/desktop/spectacle.khotkeys, and the section label makes sense.

- The "Global Keyboard Shortcuts" KCM, component "KDE Daemon" (I believe in earlier version there was a separate component "System Settings Module", which has since been merged into "KDE Daemon"). I guess KDED is actually responsible for making KHotKeys work these days, but for users that category can be a bit surprising.

Both locations seem to be in sync when I change shortcuts.

I agree that's not an ideal situation, but certainly that's more because of the technical restriction @cfeck mentioned rather than not wanting to arrange things properly.

And interstingly enough, the "Custom Shortcuts" DOES allow in its third tab to change "Arguments" and "Function".

However nobody could guess the first argument was "include pointer".

But the first tab shows a description, it could include the text:

Arguments:
- includeMousePointer (default: true)

However in the third tab, the user must guess specifying two arguments.

Ideally those two (or three) interfaces should be merged, even if technically they are created by different persons.

I chose the first menu because It looked more like the menus I alread know in all KDE applications in the setting "Configure Keys".

I didn't finish my sentence, "However in the third tab, the user must guess specifying two arguments is done using commas".

Bump.
Simply remove the mouse pointer for that kind of screenshots made from the KDE Daemon shortcuts section.
I cannot imagine someone wanting to include a mouse pointer in a rectangular region screenshot, or even an usual one - that would be a special case that Spectacle already handles, so why ruin the experience for 99% of cases?
There is already a toggle in Spectacle so that could alternate the shortcut if needed but that's just bonus points.

*** Bug 434160 has been marked as a duplicate of this bug. ***

*** Bug 435082 has been marked as a duplicate of this bug. ***

*** Bug 442074 has been marked as a duplicate of this bug. ***

*** Bug 445859 has been marked as a duplicate of this bug. ***

*** Bug 431613 has been marked as a duplicate of this bug. ***

Git commit 2fd91b51a0ce2d2cbc9f1725373fe2abeb96f19c by Nate Graham, on behalf of Antonio Prcela.
Committed on 02/12/2021 at 18:48.
Pushed by ngraham into branch 'master'.

Respect in-windows settings when launched via DBUS

Respect the settings that are set in the main window of spectacle:

- include mouse pointer

- include window titlebar and borders

Include the mouse pointer, when launched via DBUS, depending if the user set the
option to include mouse pointer or not in the checkbox 'option - include mouse pointer'.

M  +5    -5    dbus/org.kde.Spectacle.xml
M  +5    -5    desktop/org.kde.spectacle.desktop.cmake
M  +11   -10   src/SpectacleDBusAdapter.cpp
M  +5    -5    src/SpectacleDBusAdapter.h

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