gui: add non-file import/export fallbacks for text workflows

[starius]

Summary

This PR reduces Liana GUI's dependence on native file pickers for text-based workflows and keeps the shared import/export modal usable when the picker does not return a path.

On non-Nixos nix setups the wallet does not have a working file picker widget, so Export/Import buttons showed a window and immediately closed it:

ERROR rfd::backend::xdg_desktop_portal:248: pick_folder error No such file or directory (os error 2)

On Linux, Liana currently relies on rfd's XDG portal backend for file selection. In some environments that portal request fails at runtime; rfd then falls back to spawning zenity. If zenity is not available, rfd returns no path and the existing GUI treats that the same as a normal chooser cancel, so the import/export modal closes immediately. This PR adds non-file clipboard flows for text-based workflows and keeps the modal usable by falling back to manual path entry when no path is returned.

What changed

• Add direct Copy actions for shared xpubs in the installer share step while keeping the existing export buttons.
• Add PSBT clipboard flows by exposing direct copy, adding explicit paste-based import and update paths, trimming pasted input before validation, and preserving the existing file-based import flow.
• Add clipboard paths for wallet backup JSON and labels JSONL exports in settings, and add a paste-backup flow in the installer import step that reuses the same parsing path as file imports.
• Allow wallet restore in settings to start from pasted backup text.
• Keep the shared import/export modal open when the native chooser returns no path and switch it to a minimal manual path entry fallback instead of closing immediately.

[pythcoiner]

Hi, thanks for looking into this, could you share some screenshots or screencats of the UI changes, so @nondiremanuel can figure out if it fits in the flow?

[starius]

1. This is the xpub sharing screen. Note the new Copy button:

---

2. This is how Export looks like for the same screen. Normal file picker is broken on my machine, so I see the fallback (regular text input for the file path). Not beautiful, but functional.

---

3. This is how Settings -> Wallet looks like. Note the Copy button:

---

4. PSBT screen. Note Copy and Paste buttons:

---

5. Finally, Settings -> Import/Export screen. Note that many items now have Copy or Paste buttons. This screenshot is a bit outdated. I removed the Copy button from Transaction table, since does not make sense there and required too many changes to support.

[nondiremanuel]

1. This is the xpub sharing screen. Note the new Copy button:

2. This is how Export looks like for the same screen. Normal file picker is broken on my machine, so I see the fallback (regular text input for the file path). Not beautiful, but functional.

3. This is how Settings -> Wallet looks like. Note the Copy button:

4. PSBT screen. Note Copy and Paste buttons:

5. Finally, Settings -> Import/Export screen. Note that many items now have Copy or Paste buttons. This screenshot is a bit outdated. I removed the Copy button from Transaction table, since does not make sense there and required too many changes to support.

Thanks for the PR!
I personally don't find adding too many button options optimal for the UX/UI.
Can't we use the same fallback mechanism you proposed in point 2 (if I understand it correctly) for all the options? I.e. if the Export/Import fails due to file picker not available, show a modal with the option to input a path.

[starius]

@nondiremanuel

Thanks for the review!

Can't we use the same fallback mechanism you proposed in point 2 (if I understand it correctly) for all the options? I.e. if the Export/Import fails due to file picker not available, show a modal with the option to input a path.

Yes, that fallback is already implemented in this PR. When the native file picker does not return a path, the modal stays open and switches to a simple manual path input instead of closing immediately.

I personally don't find adding too many button options optimal for the UX/UI.

I agree that showing both file and clipboard actions everywhere can make the UI feel too busy.

My suggestion would be to keep clipboard actions only for short, single-line values such as xpubs, where copy/paste is likely the primary user flow anyway. In practice, xpubs are often exchanged directly between participants, for example over chat, and requiring a temporary file just adds extra steps on both sides.

For longer text content such as full backups, labels, or other larger exports, I agree that relying on file import/export plus the manual path fallback is probably the cleaner UI.

More concretely, my suggestion for the cases in this PR would be:

• Shared xpubs: keep Copy and Paste, remove file dialogs
• PSBT: keep Copy and Paste, remove file dialogs
• use file import/export for backups, labels, and similar larger artifacts
• keep the manual path fallback for all file-based flows

That seems like a reasonable compromise between usability and keeping the UI uncluttered. What do you think?

[nondiremanuel]

@nondiremanuel

Thanks for the review!

Can't we use the same fallback mechanism you proposed in point 2 (if I understand it correctly) for all the options? I.e. if the Export/Import fails due to file picker not available, show a modal with the option to input a path.

Yes, that fallback is already implemented in this PR. When the native file picker does not return a path, the modal stays open and switches to a simple manual path input instead of closing immediately.

I personally don't find adding too many button options optimal for the UX/UI.

I agree that showing both file and clipboard actions everywhere can make the UI feel too busy.

My suggestion would be to keep clipboard actions only for short, single-line values such as xpubs, where copy/paste is likely the primary user flow anyway. In practice, xpubs are often exchanged directly between participants, for example over chat, and requiring a temporary file just adds extra steps on both sides.

For longer text content such as full backups, labels, or other larger exports, I agree that relying on file import/export plus the manual path fallback is probably the cleaner UI.

More concretely, my suggestion for the cases in this PR would be:

* Shared xpubs: keep `Copy` and `Paste`, remove file dialogs

* PSBT: keep `Copy` and `Paste`, remove file dialogs

* use file import/export for backups, labels, and similar larger artifacts

* keep the manual path fallback for all file-based flows

That seems like a reasonable compromise between usability and keeping the UI uncluttered. What do you think?

I agree with your consideration, but I would still avoid having the "Copy" and "Paste" for the PSBT for the following reasons:

• Having four secondary action could be overwhelming for the user
• We have in place a logic to avoid "Export" before a PSBT has been saved, in order to avoid address reuse. If we add "Copy" we should implement (and maintain) the same logic, which I don't think it's worth it for the value added.
• We had "Copy" and "Paste" in the past but we went for "Export" and "Import" which is more user friendly in our opinion. I wouldn't re-introduce the old behavior.

[starius]

@nondiremanuel I removed unneeded changes. Now it is quite small:

• adds Copy for xpub
• adds the manual path fallback for file-based import/export

I also kept the backup retry-state fix because it is independent and still useful.

[nondiremanuel]

@nondiremanuel I removed unneeded changes. Now it is quite small:

* adds Copy for xpub

* adds the manual path fallback for file-based import/export

I also kept the backup retry-state fix because it is independent and still useful.

Thanks! I will test and we will review as soon as possible.

[nondiremanuel]

Sorry it took me some time to test. It generally looks good (at least from a non-code-review perspective) but I have a couple of comments:

1. In the "Share xpub" screen, the copy button was not supposed to substitute the "Export" one, which should still be the primary action (as in a previous screenshot you shared):

2. I would personally use "file picker" in the wording instead of "file chooser", but no strong opinion

[starius]

@nondiremanuel Thanks for checking it!
I fixed the two issues. Here are the new screenshots: