(I resend this email because the first one awaits moderator approval
since a few days, because I was not subscribed to the list when I sent it)

Hi,

we at Tails (tails.boum.org) are currently working on adding support for
TrueCrypt and VeraCrypt volumes in udisks and GNOME Disks (see also the
corresponding thread on devkit-devel [1]). A team mate will also send an
email regarding this to GNOME UX people in the next days, so you won't
see any code from us implementing a GUI design that they have not
accepted. I'm stating this so you can ignore the GUI design implications
for now.

Beside other things, we also want to support unlocking via the GVfs
udisks volume monitor, which automatically prompts the user to unlock
encrypted volumes once they are plugged in. In order to fully support
TC/VC volumes, the unlock dialog shown to the user must allow specifying
several other options than only the password, namely: keyfiles required
to unlock the file, a PIM value [2], and whether the volume is a hidden
volume, a system volume, or neither.

Doesn't sound like the greatest user experience, having to specify

a ton of arcane details like that...

The work on this part turned out more complicated than we anticipated.
The unlock dialog is not created by the GVfs monitor directly, but by
GtkMountOperation, which in turn calls
org.gtk.MountOperationHandler.AskPassword, which is part of GNOME Shell,
and which then finally creates the ShellMountPasswordDialog (please
correct me if I got anything wrong).

This means that we will have to patch a lot more, and more low-level
GNOME components than we anticipated, and we would like to ask for
advice on what the best way to solve this would be.

The only way I see is to extend GtkMountOperation (and GMountOperation)
by fields for the additional options, and create new flags in
GAskPasswordFlags, which can be passed down from GVfs to
ShellMountPasswordDialog. This could be a single "VeraCrypt-mode" flag,
or a separate flag for each of the required options I listed above.

Do you see a better way?

If you could describe the required data a bit more, it might be possible to figure out

if we can describe this in a somewhat concise way - it sounds like you need to add