Thanks for reporting.

Can you check if this is fixed in the latest continuous build?

Tester Version:
Version: 1.10.0-continuous
Build: 1-ca53637

Option to include mouse pointer is set in image grabber setting.
Taking the screenshot with ksnip shortcuts Shift+L,F,M,A and global shortcuts set in options global shortcuts, captures the mouse pointer at correct position.

But using shortcuts set in KDE Settings - Shortcuts, does not capture the mouse pointer.
Settings are like in this screenshot:

If ksnip is opened via Hotkey from Tray, no screenshot is taken. Is this expected?

My system configuration:
System: MX Linux 21 RC 1
Host: Kernel: 5.10.0-9-amd64 x86_64 bits: 64 compiler: N/A
parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-9-amd64
root=UUID= ro quiet splash
Desktop: KDE Plasma 5.20.5 wm: kwin_x11 dm: SDDM
Distro: MX-21_KDE_RC1_x64 Wildflower October 5 2021
base: Debian GNU/Linux 11 (bullseye)

Yes, I've suspected already that it only affects does KDE global shortcuts. The config for them comes from ksnip's desktop file, in there the command executes was a simple ksnip -m but for the cursor to be included you would need to call ksnip -m -c, that's what I did, I've changed the command in the desktop file. The issue could that you either didn't get the desktop file or our mouse capture via command line is broken.

Can you try to find locally on your system a file called org.ksnip.ksnip.desktop and see the capture cursor option is set, like here:

Also, can you try running ksnip from command line with ksnip -m -c and see if the mouse cursor is captured?

If ksnip is opened via Hotkey from Tray, no screenshot is taken. Is this expected?

How do you mean? Doesn't sound right though.

If ksnip is opened via Hotkey from Tray, no screenshot is taken. Is this expected?

How do you mean? Doesn't sound right though.

By default the "use tray icon" option is set. If the Print key is configured just to start ksnip (what is was on my installation by default) no screenshot is taken if ksnip was running before and is now in the task bar, even if the option "Take screenshot on start" is set. IMHO this is a bad user experience.

Can you write the steps to reproduce that? I'm not sure that I understand how "use tray icon" is related to this scenario and how you got print key to just start ksnip without taking screenshots.

Yes, I've suspected already that it only affects does KDE global shortcuts. The config for them comes from ksnip's desktop file, in there the command executes was a simple ksnip -m but for the cursor to be included you would need to call ksnip -m -c, that's what I did, I've changed the command in the desktop file. The issue could that you either didn't get the desktop file or our mouse capture via command line is broken.

Can you try to find locally on your system a file called org.ksnip.ksnip.desktop and see the capture cursor option is set

Also, can you try running ksnip from command line with ksnip -m -c and see if the mouse cursor is captured?

To my surprise, the screenshot today was captured correct with mouse pointer when using the global shortcut :-)

I also found the file org.ksnip.ksnip.desktop. It's in /usr/share/applications/
The content is fine, like this

[Desktop Action FullScreen]
Exec=ksnip -m -c

The reason why it did not work in the first try is, the content of this file is only read during login. And after installing the test version 1.10 this file was obviously not reread and thus executed without the -c flag.

The downside of this solution to put the -c flag in this file is, that if you switch the flag in the settings dialog to not capture the mouse cursor, it will not behave like you expect (tried it). And since this file is only read during login, its not an option to dynamically update it according to settings.
To solve this I would suggest, to make a new flag e.g. -s that captures the mouse cursor depending on the settings made in the GUI and write this command with -s flag into the .desktop file.
What do you think?

The downside of this solution to put the -c flag in this file is, that if you switch the flag in the settings dialog to not capture the mouse cursor, it will not behave like you expect (tried it).

It depends on what you expect, the desktop file uses the command line flags to trigger a screenshot so you either set it or not, it's detached from the GUI.

To solve this I would suggest, to make a new flag e.g. -s that captures the mouse cursor depending on the settings made in the GUI and write this command with -s flag into the .desktop file.
What do you think?

I think it's problematic from a expectation point of view because you would selectively pick some config from the GUI (capture cursor, delay maybe) and some from CLI (what type of screenshot you want). It doesn't feel right to be honest.

Using ksnip's global hotkeys would work as you expect, why don't use them?

Also, I was thinking about making triggering the actions from CLI possible, then you could configure action like you need them and call them by their name from the CLI. But that would not be part of the desktop file though. However, you can modify your desktop file locally as you prefer.

I just wanted do give a hint so other users would find this nice tool helpful and not go into the same trap than I did when using it in KDE whit the shortcurs set in KDE settings.

When using it with KDE it is configured via the KDE settings. If you change settings in the GUI like want to capture the Mouse pointer for whatever you do, people would go into the same trap than I did. The GUI setting does not do (in there point of view) what they expect. So I suggested to make a new flag that can be used in the desktop file and takes the GUI settings into account. I see nothing problematic there, its just user friendly.
If you want to use the CLI you can still do it.

I think it's problematic from a expectation point of view because you would selectively pick some config from the GUI (capture cursor, delay maybe) and some from CLI (what type of screenshot you want). It doesn't feel right to be honest.

The program is driven by CLI, so what can't be none else? I only mean an CLI flag that is used in the desktop file.

However, you can modify your desktop file locally as you prefer.

Of cause, I could edit the files on my side, but thats not my intension, thats not why I wrote this report here. I would think, the average KDE user will use it by the Print shortcut defined via the settings dialog and not via the global hotkey defined in the ksnip settings.

I only mean an CLI flag that is used in the desktop file.

Well that's the thing, there is no "desktop file only" command, if you add it, it's available everywhere.

What we could do is add two new command line options, one for delay and one for cursor, when set will take the setting from config for cursor and/or delay, respectively and ignore the one passed (or not passed via command line).

Or, we could change the desktop file to use the dbus interface when we implement dbus support for ksnip, that's also how Spectacle is called through the desktop file. For this one we would need to implement the dbus support first but that shouldn't be so complex I think.

Anyways, both would not come with the next path, this one is just for bug fixes, I would have to ask you to log a new feature request for the first one or add a comment to the dbus feature request with your expectation #323.

Well that's the thing, there is no "desktop file only" command, if you add it, it's available everywhere.
Of cause, but I don't see a problem with this.

What we could do is add two new command line options, one for delay and one for cursor, when set will take the setting from config for cursor and/or delay, respectively and ignore the one passed (or not passed via command line).

That would be great, exactly what I thought. Please do it like this (if you don't want to go with the dbus).

Or, we could change the desktop file to use the dbus interface

I also considered this but did not suggest because of the effort it makes.

Anyways, both would not come with the next path, this one is just for bug fixes
That's a pity.

Let's go with the DBus for now, it's easier for me and capacity wise I'm totally behind the feature requests that keep pilling up. For now the cursor is captured so I'll be closing this issue as I'm releasing 1.9.2 soon.