Add qubes-qvm-screenshot-tool dom0 salt recipe deployment

[tlaurion]

Commitment

I confirm that I have read the following resources:

• How to ask questions The Smart Way
• Writing the perfect question
• Question checklist
• Could you please make my preference the default?

Current problem (if any)

Dom0 screenshot and setting preferences shortcuts is not so straightforward for end users. One amazing project was put under contrib packages, but bootstrapping first package installation is also not straightforward for end users.

Proposed solution

It would be really helpful to offer dom0 installation of https://github.com/QubesOS-contrib/qubes-qvm-screenshot-tool with a dom0 salt recipe, binding xfce alt-printscreen and printscreen keyboard shortcuts to both KDE and Xfce.

The value to a user, and who that user might be

Sharing a windows content or whole desktop through copying it directly to proper domu is already properly resolved by https://github.com/QubesOS-contrib/qubes-qvm-screenshot-tool. On system reinstallation, it should be as easy to deploy as qusal makes it for other tools.

Of course this is my preference. Not sure why this is not the default yet and in contrib repo, but that tool is available and superior to the default. Trying it is adopting it, with space for improvement upstream for it to eventually become the default.

[ben-grande]

I rewrite every script added to Qusal to follow some coding rules and I as far as I can see, I will need to rewrite that tool completely. Can you please inform what features you use from that tool or if you know someone that uses it, what they most need?

• Is hosting on imgurl really necessary? I am not okay with automatically hosting on any service, it also requires curl installed and network connectivity.
• Is opening file manager commonly used? I am ok with this part.
• Is copy image to clipboard commonly used? I am ok with this but it expects the target qube to have xclip or maybe xsel installed.
• Is editing the image in dom0 really necessary? Requires ImageMagick or deepin-screenshot. Seems that this task of drawing on a screenshot should not be delegated to dom0. If editing a screenshot is really necessary, sending to a qube that is specialized in that seems better.

I don't commonly do snapshots but from seeing forum posts, I can see it is very common. I can see how a 3 step solution:

1. screenshot
2. qvm-copy-to-vm
3. open nautilus or saved to clibpoard

Can be converted to a single option to export to a qube, better usability.

Of course this is my preference. Not sure why this is not the default yet and in contrib repo, but that tool is available and superior to the default. Trying it is adopting it, with space for improvement upstream for it to eventually become the default.

If you just want Qusal to bootstrap by enabling the contrib repo and downloading the tool from the contrib repo, although that is possible, I am still thinking towards writing my own version. I know these rewrites takes me some time but the end result is much better, in my point of view, of course. This, of course, depends on how you answer the questions above.

[tlaurion]

@ben-grande : I think an iterative approach would be delightful here

1. Bootstrap the contrib repos, install key deployment and repo url changes if cacher installed
2. Deploy qubes-qvm-screenshot
3. Modify qubes-qvm-screenshot

Base logic of this is, if I understand contribution and upstreaming correctly, contrib is first step prior of adoption under main repos.

Can be converted to a single option to export to a qube, better usability.
Absolutely.

The main reason I use it is for print screen and alt-printscreen replacement, that is, to only select part of the screen related to a qube window prior of having the tool ask what to do next. Nor ally that is simply to call the qvm-copy to desired vm and that's it.

I agree that editing with imagemagik is less than efficient, but I'm not aware of the other use cases like paste bin. Afterall, if final screenshot is in desired vm, you can then edit it if needed or add text etc from better tools there.

The main thing here is really to have contrib repos activated alongside all qusal helpers (cacher) and then deploy that tool as is + keyboard shortcut remappings (xfce and KDE).

Makes sense?

[ben-grande]

Yes, it makes sense. I started doing the tool in the meantime because I didn't want to add a tool from the contrib repository that has unnecessary stuff.

Base logic of this is, if I understand contribution and upstreaming correctly, contrib is first step prior of adoption under main repos.

Most things I see in contrib are never added to the main repos. This is why most things I did contribute to Qubes either make to the default installation or don't make to contrib at all, as I don't see a value in that due to low reviews and actions.

• where "python" modules go to die
• my comment about contributed packages

So, I either wait for upstream to have enough time to review mine or anybody package to be added to the QubesOS-contrib repository or I develop them by myself. So far, I've been doing the latter, but for bigger projects such as split-dm-crypt or split-browser, I won't copy it because they require quite some work and upstream is responsive.

I will probably finish the screenshot script and add the option to add the contrib repos later on, as it might benefit in the future users who use contributed packages.

[ben-grande]

The main thing here is really to have contrib repos activated alongside all qusal helpers (cacher) and then deploy that tool as is + keyboard shortcut remappings (xfce and KDE).

I know how to do that with Xfce using xfconf-query, but with KDE, I don't know how to set the shortcut via the command-line. Do you?

[tlaurion]

From what I can gather, it would look like something along the lines of:

kwriteconfig5 --file kglobalshortcutsrc --group KWin --key TakeScreenshot 'screenshot_command,PrintScreen,PrintScreen'

kwriteconfig5 --file kglobalshortcutsrc --group KWin --key TakeScreenshotWindow 'screenshot_command -active_window,Alt+PrintScreen,Alt+PrintScreen'

kquitapp5 kglobalaccel && kglobalaccel5 &

[ben-grande]

From what I can gather, it would look like something along the lines of:

kwriteconfig5 --file kglobalshortcutsrc --group KWin --key TakeScreenshot 'screenshot_command,PrintScreen,PrintScreen'

kwriteconfig5 --file kglobalshortcutsrc --group KWin --key TakeScreenshotWindow 'screenshot_command -active_window,Alt+PrintScreen,Alt+PrintScreen'

kquitapp5 kglobalaccel && kglobalaccel5 &

Couldn't do it with KDE, did not understand why... Tried with --group khotkeys and the keysym is named Print and not PrintScreen.

Soon I will push the script with Xfce keyboard being set, if you can do it with KDE, I am open to contributions.

[ben-grande]

Tool is present now. I just tested the shortcut on Xfce and it is working, but I am a KDE user and KDE shortcut could not be done... reopening until it is done by contribution, as I couldn't do it now. Probably need to look at qdbus and kglobalaccel.

[tlaurion]

@ben-grande

reopening until it is done by contribution, as I couldn't do it now. Probably need to look at qdbus and kglobalaccel

Was wrongly closed by rewritting git history in last commits? (should review other issues maybe fitting in that time-window)

Will try to allocate time into testing this (in my todos)

[ben-grande]

@ben-grande

reopening until it is done by contribution, as I couldn't do it now. Probably need to look at qdbus and kglobalaccel

Was wrongly closed by rewritting git history in last commits? (should review other issues maybe fitting in that time-window)

Yes, due to removing mirage tarball retroactively.

Will try to allocate time into testing this (in my todos)

Thanks.

[tlaurion]

Cross-referencing to upstream QubesOS/qubes-issues#953 (comment)

[ben-grande]

Monitoring dbus while modifying KDE screenshots via the GUI

method call time=1718099529.334780 sender=:1.102 -> destination=org.kde.kglobalaccel serial=111 path=/kglobalaccel; interface=org.kde.KGlobalAccel; member=setForeignShortcutKeys
   array [
      string "khotkeys"
      string "{b37beeee-9dd2-43cb-bd18-5ee8f6cd9799}"
      string "Custom Shortcuts Service"
      string "Take Screenshot"
   ]
   array [
      struct {
         array [
            int32 16777225
            int32 0
            int32 0
            int32 0
         ]
      }
   ]
signal time=1718099529.345867 sender=:1.18 -> destination=(null destination) serial=1285 path=/kglobalaccel; interface=org.kde.KGlobalAccel; member=yourShortcutsChanged
   array [
      string "khotkeys"
      string "{b37beeee-9dd2-43cb-bd18-5ee8f6cd9799}"
      string "Custom Shortcuts Service"
      string "Take Screenshot"
   ]
   array [
      struct {
         array [
            int32 16777225
            int32 0
            int32 0
            int32 0
         ]
      }
   ]

...

method call time=1718099529.370029 sender=:1.102 -> destination=org.kde.kglobalaccel serial=121 path=/component/khotkeys; interface=org.kde.kglobalaccel.Component; member=allShortcutInfos

[ben-grande]

If upstream accepts me as the new maintainer, this issue can be closed and KDE shortcuts issue will be redirected to upstream ticketing system.

[ben-grande]

I still can't configure KDE shortcuts via the command-line. This is not something I plan to spend more time on. Screenshot tool was implemented and even tried to add to upstream. Closing as won't do KDE shortcuts.