[Contribution] qvm-screenshot-tool

[marmarek]

Community Dev: @ben-grande (originally @evadogstar)
Repo: https://github.com/ben-grande/qubes-qvm-screenshot-tool

---

Reported by axon on 16 Feb 2015 11:02 UTC
The ability send dom0 screenshots directly to an AppVM/DispVM from the screenshot app is an oft-requested feature (see below). The ability to transfer saved screenshot files from dom0 to other VMs is already available, but it is neither obvious nor easy for most users to do this.

User requests/queries about this:
https://groups.google.com/d/topic/qubes-devel/m8TfyvSqvf4/discussion
https://groups.google.com/d/topic/qubes-devel/CwSPqtPYTRQ/discussion
https://groups.google.com/d/topic/qubes-devel/_a7KxHbkSJo/discussion
https://groups.google.com/d/topic/qubes-users/l6vOqhsd7ss/discussion
https://groups.google.com/d/topic/qubes-users/etxwrc6rsIM/discussion
https://groups.google.com/d/topic/qubes-users/_7FzKv6eJqA/discussion

Migrated-From: https://wiki.qubes-os.org/ticket/953

[marmarek]

Some details here: https://groups.google.com/d/msgid/qubes-devel/20150708022217.GH900%40mail-itl

[ptitdoc]

What about a tool in dom0 that scan changes in ~/QubesOutgoing/[VMname]/ folder and send it to the AppVM ~/QubesIncoming/dom0 when available ?

For instance, when you take screenshots, you just have to save it to the right folder.

[marmarek]

I think the best solution is to use #1324 (qvm-copy-to-vm tool for dom0)
and make it a handler for screenshooting tool.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[mfc]

fyi with KSnapshot (the current screenshot tool) one cannot screenshot a specific window, freehand region, etc., even when selected. Such functionality would be quite helpful for creating Qubes documentation.

[marmarek]

Are you sure? I've just tried and it seems to work well:

1. Press Print Screen to start the tool
2. Select capture mode
3. Click "Take a New Snapshot"
4. Select region/window/whatever
5. Confirm with Enter (or double-click) - instructions are on the
   screen.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[mfc]

never mind! worked great, thanks for the steps.

I misunderstood how it worked, I thought changing the settings would change the default of pressing Print Screen. Instead one has to select Take a New Snapshot.

[Jeeppler]

Ksnapshot is getting a new version for KDE 5 based on KScreenGenie. On which KDE version will Qubes R3.2 or 4.0 be based on?

[andrewdavidwong]

On which KDE version will Qubes R3.2 or 4.0 be based on?

The plan is to use KDE 5.

[Jeeppler]

Is there any usable Qubes R4.0 or R3.2 available to develop the screenshot tool?

[marmarek]

I'm going to upload some preliminary R3.2 image somehow today/tomorrow.
Anyway this isn't much different than R3.1 - see: #1324 (comment)

[Jeeppler]

@marmarek I think the Desktop Entry solution, you mentioned in the comment, has several draw backs. First it does not work on all desktop environments and secondly you have to open the PNG file, as far as I understand it.

For my understanding it would be better to have a screen shoot tool which invokes the qvm-move-to-vm command. The tools should move the screenshot directly to a qube and only ask to start the destination qube if the destination qube is not running.

I think KSnapshot is a really nice tool to take snapshots with, but I don't know if it works reliable on XCFE or other desktop environments.

[marmarek]

It is simply available as one of applications to open screenshot with, see here:

This one is from Xfce4. In KDE it lands under "Open with" menu (or "Send to" in KDE4).

[Jeeppler]

Looks good, but what should be developed or created to be able to close this issue?

[marmarek]

A tool to ask for target VM name - qvm-move-to-vm-prompt

[Jeeppler]

What would be the preferred programming language and graphical toolkit to develop such a prompt? Should it look like the prompts Qubes OS already has to copy files from one VM to another?

[marmarek]

As usual - python. As for toolkit - currently it is mostly in Qt (especially the current qrexec confirmations). But since the long term goal is to implement new Qubes Manager in GTK and to add GNOME support, GTK is also ok. If it doesn't matter for you, I'd choose GTK.

[Jeeppler]

Is it possible to have access to the Qubes API via Python3?

[marmarek]

On Thu, May 19, 2016 at 01:57:54AM -0700, Jeppler wrote:

Is it possible to have access to the Qubes API via Python3?

Not yet, unfortunately...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[greenrd]

Unfortunately "send to" in KSnapshot does not currently work - it says "qvm-run: error: To many arguments" [sic]. Should I file another bug for that?

[marmarek]

@greenrd it isn't done yet - "Other application" option you see there is not what is meant to be used here.

[Jeeppler]

I think it would be a good idea to schedule this task till Qubes OS uses KDE 5 and Python 3.

[tlaurion]

@andrewdavidwong

From OP
"The ability send dom0 screenshots directly to an AppVM/DispVM from the screenshot app is an oft-requested feature (see below). The ability to transfer saved screenshot files from dom0 to other VMs is already available, but it is neither obvious nor easy for most users to do this."

It is still geeky to deploy, is not deployed as default and requires users to customize things.

As @Che15ea just replied, I do not think original goals of opened ticket are met. If that is a goal, then the default printscreen and at-printscreen shortcuts should be already customized and qvm-screenshot-tool deployed by default under Q4.2?

[Che15ea]

@andrewdavidwong

From OP "The ability send dom0 screenshots directly to an AppVM/DispVM from the screenshot app is an oft-requested feature (see below). The ability to transfer saved screenshot files from dom0 to other VMs is already available, but it is neither obvious nor easy for most users to do this."

It is still geeky to deploy, is not deployed as default and requires users to customize things.

As @Che15ea just replied, I do not think original goals of opened ticket are met. If that is a goal, then the default printscreen and at-printscreen shortcuts should be already customized and qvm-screenshot-tool deployed by default under Q4.2?

I think so, crop and send to vm is a function that everyone needs and all my journalist and activist friends start to be frustrated about Qubes at this point. It should not take every user's 20 minutes to setup.

[DemiMarie]

@Che15ea I agree with this. I think this should be installed by default. @marmarta what do you think?

[unman]

Once again, different experiences. The people I support don't have issues with copying files out of dom0 , regardless of their level of experience. They tend NOT to use this package, and just use a screen shot tool in dom0.

[lorenzog]

Cross-posting here (just noticed this thread, apologies for the duplicate) from #5809 (comment)

TL;DR

Save this in dom0 and make executable:

#!/bin/sh
# find current window
WINDOW_ID=$(xprop -root _NET_ACTIVE_WINDOW | cut -d ' ' -f 5 | tr -d ',')
TARGET_VM=$(xprop -id $WINDOW_ID _QUBES_VMNAME | cut -d ' ' -f 3 | tr -d ''')
# save to clipboard, using rectangular selection
xfce4-screenshotter -c -r
# send to TARGET
xclip -out -sel c -t image/png | qvm-run --pass-io $TARGET_VM 'xclip -sel c -t image/png'

Go to settings and map the 'print screen' key to the script above.
This will send the screenshot to the VM in focus when pressing 'print screen'.
I'm still looking for a solution to have a nice dialog to ask the user which VM they want to send the screenshot to - something like the dialog for 'qvm-copy'.

[UndeadDevel]

For anyone who is having trouble getting @lorenzog 's code to work (e.g. xclip not installed by default on Qubes 4.1 dom0 and the method of grabbing focused VM throws syntax error for me), here is a different version:

#!/bin/sh
# lets the user take a screenshot based on rectangular selection and sends it to the currently focused VM

CUR_WIN_ID=`xdotool getwindowfocus`
CUR_VM=`xprop _QUBES_VMNAME -id $CUR_WIN_ID | cut -d \" -f 2`

if [[ "$CUR_VM" != "_QUBES_VMNAME:  not found." ]]; then
	xfce4-screenshooter -r -o "qvm-copy-to-vm $CUR_VM"
	notify-send "Screenshot sent!" "Your selection has been sent as a screenshot to $CUR_VM!"
fi

[lorenzog]

For anyone who is having trouble getting @lorenzog 's code to work (e.g. xclip not installed by default on Qubes 4.1 dom0 and the method of grabbing focused VM throws syntax error for me), here is a different version:

Hi! Thanks for the update - in fact, as you noticed xclip stopped working since the ability to copy images with mime-type image/png disappeared from the latest version. There's a deep rabbit hole that I haven't got into yet fully and probably never will.

I can't seem to get your script to work though - mind you, I'm using i3 and not xfce at the moment, but the -o option doesn't seem to pass the output to the target VM.

[lorenzog]

Ok, I went down the rabbit hole :) this script now works in Qubes 4.1. It requires xclip to be present on the destination qube.

#!/bin/sh
WINDOW_ID=$(xprop -root _NET_ACTIVE_WINDOW | cut -d ' ' -f 5 | tr -d ',')
echo "Window ID: $WINDOW_ID"
TARGET_VM=$(xprop -id $WINDOW_ID _QUBES_VMNAME | cut -d ' ' -f 3 | tr -d '"' )
echo "Target VM: $TARGET_VM"
DEST=$(mktemp)
echo "Dest: $DEST"
xfce4-screenshooter -r -s "$DEST"
cat "$DEST" | qvm-run --pass-io $TARGET_VM -- xclip -sel c -t image/png -l 1
rm "$DEST"

What needed to change:

1. xclip was "waiting" for the receiver (qvm-run) to pick up the content of the clipboard with the appropriate "target", and because qvm-run never asked for a target, it was returning an error (and an empty clipboard)
2. The screenshot is now saved to a temporary location on disk (mkstemp is not available in dom0?)
3. The -l 1 instructs xclip to only listen for one selection (e.g. your target application in the qube) before closing itself. This means that screenshots won't be available more than once, unless you run a clipboard manager like parcellite.

[UndeadDevel]

I can't seem to get your script to work though - mind you, I'm using i3 and not xfce at the moment, but the -o option doesn't seem to pass the output to the target VM.

Works perfectly for me on a pretty fresh Q4.1 install and doesn't require installing any packages...
It would be nice if the much more feature-rich tool was included by default in the qubes repo, though. I just learned about QubesOS-contrib packages...so never mind.

[CumpsD]

I'm still looking for a solution to have a nice dialog to ask the user which VM they want to send the screenshot to - something like the dialog for 'qvm-copy'.

This would be an awesome addition. Or the ability to save the screenshot in the global clipboard, so one can paste it in a VM of choice after grabbing the screenshot.

[CumpsD]

If it helps, I made this:

$ cat qvm-copy-file-to-clipboard 
#!/usr/bin/bash
set -e -o pipefail
#
# The Qubes OS Project, http://www.qubes-os.org
#
# Copyright (C) 2015  Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
#
#

if [ $# -lt 1 ] ; then
    echo usage: $0 'file'
    exit 1
fi

#echo "base64 \"$@\" > /var/run/qubes/qubes-clipboard.bin"
base64 "$@" > /var/run/qubes/qubes-clipboard.bin

#echo "echo -n dom0 > /var/run/qubes/qubes-clipboard.bin.source"
echo -n dom0 > /var/run/qubes/qubes-clipboard.bin.source

if [ "${0##*/}" = "qvm-copy-file-to-clipboard" ]; then
	rm -rf -- "$@"
fi

I then configured this as a custom action in the built in dom0 screenshot tool:

After I take a screenshot, it copies the file as base64 in the inter-qube clipboard, which I can then CTRL+SHIFT+V into my target qube and run this to get the file in my clipboard to CTRL+V it into github/slack/....

xclip -o | base64 -d | xclip -i -selection clipboard -t image/png

I need to come up with a nice way to trigger this last line in my target VM after pressing CTRL+SHIFT+V, maybe bind the script to yet another keybind?

---

edit:

I added the following to dom0:

$ cat qvm-parse-base64-clipboard 
#!/bin/bash

# Script should be located at /usr/bin/qvm-parse-base64-clipboard

CUR_WIN_ID=`xdotool getwindowfocus`
CUR_VM=`xprop _QUBES_VMNAME -id $CUR_WIN_ID | cut -d \" -f 2`

if [[ "$CUR_VM" != "_QUBES_VMNAME:  not found." ]]; then
  qvm-run $CUR_VM 'xclip -o | base64 -d | xclip -i -selection clipboard -t image/png'
  notify-send "Screenshot saved!" "Your screenshot is available in the clipboard of $CUR_VM"
fi

and bound CTRL+SHIFT+S to it in the global keyboard.

So now I grab a screenshot, it goes on the global clipboard, I select my VM and press CTRL+SHIFT+V to get it in the qube and CTRL+SHIFT+S to transform it into a screenshot file to paste in slack :)

[tlaurion]

Referred upstream to work done by @ben-grande for reuostreaming and the downstream under contrib at evadogstar/qvm-screenshot-tool#10

Discussion leading to implemtstiom changes prior of qusal inclusion happened at ben-grande/qusal#22

This is a cleaner version of the script, passing through qvm-copy and removing dom0 file edition, limiting the scope to full-screen and active window screenshoting, also removing uploading option which is delegated to be done on the qube where those edit/uploading actions should be done IMO.

As current state, qvm-screenshot per qusal deploys it correctly and works out if the box through qusal. Unfortunately, setting shortcuts in KDE is not so straightforward as it is for xfce, and qusal deploys KDE per deployment of dom0 salt application.

In current state, this means switching from xfce/KDE when needs come to taking screenshot, which to be honest makes sense, since xfce is what is expected to be used by default. So screenshot helper for xfce showing full-screen UX is what people would expect in full-screen screenshot anyway.

Now the question is how to upstream those changes so they make their way to contrib repo.

For commits and accountability I'm tagging @ben-grande here.

I guess the improvements of the scripts should land as a PR against https://github.com/QubesOS-contrib/qubes-qvm-screenshot-tool per contrib guidelines so this ticket can be closed and improvements issues can be opened.

qvm-screenshot is a contrib project under qubes-qvm-screenshot-tool, and contrib guidelines encourage PR against already existing contrib repositories.

[ben-grande]

Referred upstream to work done by @ben-grande for reuostreaming and the downstream under contrib at evadogstar/qvm-screenshot-tool#10

Discussion leading to implemtstiom changes prior of qusal inclusion happened at ben-grande/qusal#22

This is a cleaner version of the script, passing through qvm-copy and removing dom0 file edition, limiting the scope to full-screen and active window screenshoting, also removing uploading option which is delegated to be done on the qube where those edit/uploading actions should be done IMO.

Changes can also be seen in the commit message ben-grande/qusal@134a26a.

As current state, qvm-screenshot per qusal deploys it correctly and works out if the box through qusal. Unfortunately, setting shortcuts in KDE is not so straightforward as it is for xfce, and qusal deploys KDE per deployment of dom0 salt application.

In current state, this means switching from xfce/KDE when needs come to taking screenshot, which to be honest makes sense, since xfce is what is expected to be used by default. So screenshot helper for xfce showing full-screen UX is what people would expect in full-screen screenshot anyway.

You don't need to change from KDE to Xfce, you just need to configure the shortcuts manually for the time being.

Now the question is how to upstream those changes so they make their way to contrib repo.

For commits and accountability I'm tagging @ben-grande here.

I guess the improvements of the scripts should land as a PR against https://github.com/QubesOS-contrib/qubes-qvm-screenshot-tool per contrib guidelines so this ticket can be closed and improvements issues can be opened.

qvm-screenshot is a contrib project under qubes-qvm-screenshot-tool, and contrib guidelines encourage PR against already existing contrib repositories.#953 (comment)

About contributing upstream, the repos QubesOS-contrib/qubes-qvm-screenshot-tool and evadogstar/qvm-screenshot-tool differ since 2020. My version also removes a Imgurl, a tool which original author @evadogstar finds important. I don't know how many people it would affect if Imgurl was removed. Although all projects have the same goal of taking screenshot and moving to qubes, they differ in features. I did clean the code extensively more than add features.

I committing enhancements to QubesOS-Contrib is possible, but then it would differ from upstream evadogstar repo. I committing to evadogstar, but they don't open PRs to QubesOS-Contrib for new changes. There is no clear path to upstream it.

[marmarek]

Since #7739 is implemented, we have a way to define per-package maintainers now. So, I have a proposal to improve the screenshoting situation:

1. Move https://github.com/QubesOS-contrib/qubes-qvm-screenshot-tool to the main organization (and also to the main repository)
2. Add @ben-grande and/or @evadogstar (if you agree) as the maintainer of the package.
3. Configure builder to require 2 signed tags on this package - with the idea primary maintainer cares for the functionality and general code shape, and the other person is only verifying if no backdoors or obvious security issues are added (such checking of incremental changes shouldn't be much work given the size of this tool). The second tag can be from the other maintainer, or from qubes core team (for example @fepitre or @DemiMarie or me or ...). To be clear, the general direction and code shape of the tool would be up to the primary maintainer, I do not want nitpicking like "this could be done a bit faster another way" blocking that second tag.

There will need to be a bit coordination needed for which we don't have tooling yet, but I think we can manage even manually for now. Specifically: how to coordinate between those 2 people pushing tags. Ideally, we'd have some system where a PR(?) is merged only when two tags are prepared to be pushed - and then PR merge and two tags are pushed to the repo at the same time. But, in the meantime, we can simply have few people with push access to the repo, and have them coordinate via comments/mail/IM etc. This means at some times (before the second tag is pushed) builder will refuse to fetch the sources, and maybe at times some revert will be needed (when second reviewer spot some issue), but that's IMO still good enough for now.

What do you think about this proposal?

[ben-grande]

1. Move https://github.com/QubesOS-contrib/qubes-qvm-screenshot-tool to the main organization (and also to the main repository)

I also think it makes sense. It is just some lines of code and leaving it on QubesOS-Contrib make people wait for the original author to make changes while transferring it to the main organization is easier to know where to contribute to (directly).

2. Add @ben-grande and/or @evadogstar (if you agree) as the maintainer of the package.

I am not sure if if you agree was intended for both people or just the name close to the phrase, therefore I'm answering yes.

3. Configure builder to require 2 signed tags on this package - with the idea primary maintainer cares for the functionality and general code shape, and the other person is only verifying if no backdoors or obvious security issues are added (such checking of incremental changes shouldn't be much work given the size of this tool). The second tag can be from the other maintainer, or from qubes core team (for example @fepitre or @DemiMarie or me or ...). To be clear, the general direction and code shape of the tool would be up to the primary maintainer, I do not want nitpicking like "this could be done a bit faster another way" blocking that second tag.

Multiple taggers that have at least someone not from ITL would be a nice experiment. I don't want to expand this too much on the screenshot related thread, but lets consider there are at least 3 authorized keys, requiring 2 keys to be valid and 2 of the keys are not used by ITL: me, @fepitre and @evadogstar. Considering ITL keys to be always trustworthy, at least 1 signature needs to come from ITL, else 2 non-ITL keys could sign a malicious commit.

@marmarek suggested this on #7739.

I don't exclude more complex schemes (3 tags from any of A,B,C,D,E or 2 tags if at least one is made by X), but lets start with a simpler option first.

Which doesn't seem to have been completed as far as I know: if at least one is made by X.

There will need to be a bit coordination needed for which we don't have tooling yet, but I think we can manage even manually for now. Specifically: how to coordinate between those 2 people pushing tags. Ideally, we'd have some system where a PR(?) is merged only when two tags are prepared to be pushed - and then PR merge and two tags are pushed to the repo at the same time. But, in the meantime, we can simply have few people with push access to the repo, and have them coordinate via comments/mail/IM etc. This means at some times (before the second tag is pushed) builder will refuse to fetch the sources, and maybe at times some revert will be needed (when second reviewer spot some issue), but that's IMO still good enough for now.

What do you think about this proposal?

Coordination via comments on issues and PR is my preferred method of contact if I become maintainer.

[ben-grande]

Ping.

[ben-grande]

Maintainer @evadogstar has account deleted, the package is "orphaned".

The repo QubesOS-contrib/qubes-qvm-screenshot-tool has lost it's upstream and community maintainer.

The repo evadogstar/qvm-screenshot-tool had some issues opened by the Qubes Core Team at the time, such as @fepitre (to sync commits with Qubes) and @ninavizz (UX), which could be useful improvements ( I don't remember fully their contents)..... how to get that back now that upstream has deleted it's account?

---

Now on the policy side of opening issues to community owned repos, those things can happen (deletion)... if they were open in qubes-issues, at least a proper backup could have been made.

[fepitre]

I think we can just either drop this package in favor to another one or consider it as the upstream. I don't think we specially need to move it to QubesOS directly. I'm fine to add you as maintainer and we would need to have at least me to add another tag. This is similar to https://github.com/QubesOS-contrib/qubes-app-split-browser where I'm reviewing most of the work done in PR and the maintainer is already preparing everything, I just need to add a tag on it for triggering the build process.

[ben-grande]

Fork made: https://github.com/ben-grande/qubes-qvm-screenshot-tool

[fepitre]

Fork made: https://github.com/ben-grande/qubes-qvm-screenshot-tool

Please tell me when you have tested it with builderv2 in order to add it to the CI too.

[ben-grande]

Build with qubes-builderv2 tested and succeeding.

This is the config I used to build, I understand that key-dirs, maintainers and other key related options will be changed to your key and to use tags instead of signed commits.

---

git:
  baseurl: https://github.com
  prefix: ben-grande/
  branch: main
  maintainers:
    - DF3834875B65758713D92E91A475969DE4E371E3

key-dirs:
  - ../qusal-builder/keys/
backend-vmm: xen
debug: true
verbose: true
qubes-release: r4.2
timeout: 3600

skip-git-fetch: false
fetch-versions-only: false

distributions:
  - host-fc37

components:
  - builder-rpm:
      branch: main
      packages: false
      url: https://github.com/QubesOS/qubes-builder-rpm
      maintainers:
        - 0064428F455451B3EBE78A7F063938BA42CFA724
  - qubes-qvm-screenshot-tool:
      branch: master
      verification-mode: less-secure-signed-commits-sufficient
      maintainers:
        - DF3834875B65758713D92E91A475969DE4E371E3