ben-grande / qusal

Salt Formulas for Qubes OS.
19 stars 7 forks source link

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

Open tlaurion opened 7 months ago

tlaurion commented 7 months ago

Commitment

I confirm that I have read the following resources:

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 commented 7 months ago

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?

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 commented 6 months ago

@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 commented 6 months ago

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.

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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)

tlaurion commented 6 months ago

Hmmmm. sems like BOOTSTRAPP.md should place dev missing requirement between dom0 [...] and sys-cacher (otherwise dotfiles-copy-x11-home and dotfiles-copy-x11-skel are expected to be deployed but aren't?)

ben-grande commented 6 months ago

@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.

ben-grande commented 6 months ago

Hmmmm. sems like BOOTSTRAPP.md should place dev missing requirement between dom0 [...] and sys-cacher (otherwise dotfiles-copy-x11-home and dotfiles-copy-x11-skel are expected to be deployed but aren't?)

Can you please clarify what dev missing requirement between dom0 [...] and sys-cacher means? I see sys-cacher.configure.sls with dotfiles.copy-x11 included.

tlaurion commented 6 months ago

Hmmmm. sems like BOOTSTRAPP.md should place dev missing requirement between dom0 [...] and sys-cacher (otherwise dotfiles-copy-x11-home and dotfiles-copy-x11-skel are expected to be deployed but aren't?)

Can you please clarify what dev missing requirement between dom0 [...] and sys-cacher means? I see sys-cacher.configure.sls with dotfiles.copy-x11 included.

Disregard. Hid comment.

deployed salt recipes were not in sync (setup was not ran after git repo copied over dom0...)

tlaurion commented 5 months ago

Cross-referencing to upstream https://github.com/QubesOS/qubes-issues/issues/953#issuecomment-2057613527

ben-grande commented 3 months ago

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