Allow to open more than one file in the same DispVM

[marmarek]

Reported by joanna on 8 Apr 2014 09:14 UTC
Usecase: somebody sends me 10 photos via email and I would like to open all of them in one DispVM under Shotwell (or other default app) and be able to easily browse through them.

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

[marmarek]

Comment by marmarek on 8 Apr 2014 11:02 UTC
Are we really want it for R2-rc1? It doesn't look like 5min feature...
Problems:

1. Current "open-in-vm" protocol allow only to pass one file, because we want the protocol simple AND allow to pass possibly modified file back.
2. Source VM do not know DispVM name in which file was opened, so it can't simply "qvm-open-in-vm DISPVM_NAME" other files. But the user see the name (in window title bar), so can do it manually.

Situation is much better when you receive ''archive'' of 10 photos - you can simply open that archive in DispVM, extract it there and browse photos.

[marmarek]

Comment by marmarek on 8 Apr 2014 11:02 UTC
Are we really want it for R2-rc1? It doesn't look like 5min feature...
Problems:

1. Current "open-in-vm" protocol allow only to pass one file, because we want the protocol simple AND allow to pass possibly modified file back.
2. Source VM do not know DispVM name in which file was opened, so it can't simply "qvm-open-in-vm DISPVM_NAME" other files. But the user see the name (in window title bar), so can do it manually.

Situation is much better when you receive ''archive'' of 10 photos - you can simply open that archive in DispVM, extract it there and browse photos.

[marmarek]

Comment by joanna on 8 Apr 2014 11:28 UTC
Yes, I was thinking about using the existing protocol, something ala compress and open-in-dispvm yo suggested. Just not sure if we could safely use the Linux default archiver program (say, tgz or zip) to compress a number of untrusted files. Hm... I think actually we should be able to do that, because AFAIU the packing operation should treat the files as "amorphic" stream of bytes without interpreting them in any way. Hm, but I could also imagine some "smart" archiver that tries to use a different algo params depending on whether it compresses photos vs. text vs. code, which might then involve actually parsing the files before compressing them, which would be not acceptable to us.

But, assuming we can be sure that, say, doing "tar cvzf archive-to-send.tgz files-see-*" doesn't parse the input files, perhaps we could have a handy script to handle this automagically? By this I mean: when a user selected a group o files (i.e. >1) then instead of "Open in DispVM" (which should be grayed) we have "Open files in DispVM".

Alternatively, if changing entries in Nautilus menu depending on the number of selected files was non-trivial, we could have the standard "Open in DispVM" behave differently depending on whether there is only one file selected vs. more-than-one-selected?

[marmarek]

Comment by joanna on 8 Apr 2014 11:28 UTC
Yes, I was thinking about using the existing protocol, something ala compress and open-in-dispvm yo suggested. Just not sure if we could safely use the Linux default archiver program (say, tgz or zip) to compress a number of untrusted files. Hm... I think actually we should be able to do that, because AFAIU the packing operation should treat the files as "amorphic" stream of bytes without interpreting them in any way. Hm, but I could also imagine some "smart" archiver that tries to use a different algo params depending on whether it compresses photos vs. text vs. code, which might then involve actually parsing the files before compressing them, which would be not acceptable to us.

But, assuming we can be sure that, say, doing "tar cvzf archive-to-send.tgz files-see-*" doesn't parse the input files, perhaps we could have a handy script to handle this automagically? By this I mean: when a user selected a group o files (i.e. >1) then instead of "Open in DispVM" (which should be grayed) we have "Open files in DispVM".

Alternatively, if changing entries in Nautilus menu depending on the number of selected files was non-trivial, we could have the standard "Open in DispVM" behave differently depending on whether there is only one file selected vs. more-than-one-selected?

[marmarek]

Comment by marmarek on 8 Apr 2014 11:31 UTC
Sounds doable. Still - do we want it for R2-rc1?

[marmarek]

Comment by marmarek on 8 Apr 2014 11:31 UTC
Sounds doable. Still - do we want it for R2-rc1?

[marmarek]

Modified by joanna on 13 Apr 2014 10:54 UTC

[marmarek]

Modified by joanna on 13 Apr 2014 10:54 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:02 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:02 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:06 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:06 UTC

[andrewdavidwong]

On 2016-07-18 01:27, Jeremy Rand wrote:

Might there be any plans to allow sending a directory to a DispVM?
Right now in Qubes 3.2 rc1, attempting to do so from the file manager
GUI in a Fedora 23 template yields this error:

qopen-in-vm: Fatal error: send file to dispVM (error type: Is a directory)

The desired behavior, I think, would be to open a file manager window
inside the DispVM that includes the full contents of the selected
directory. This way, files could be edited in a DispVM that depend on
other nearby files (e.g. document files that reference image files).

[andrewdavidwong]

On 2016-07-18 01:27, Jeremy Rand wrote:

Might there be any plans to allow sending a directory to a DispVM?
Right now in Qubes 3.2 rc1, attempting to do so from the file manager
GUI in a Fedora 23 template yields this error:

qopen-in-vm: Fatal error: send file to dispVM (error type: Is a directory)

The desired behavior, I think, would be to open a file manager window
inside the DispVM that includes the full contents of the selected
directory. This way, files could be edited in a DispVM that depend on
other nearby files (e.g. document files that reference image files).