[Question] Cannot open remote files

xournalpp / xournalpp

Xournal++ is a handwriting notetaking software with PDF annotation support. Written in C++ with GTK3, supporting Linux (e.g. Ubuntu, Debian, Arch, SUSE), macOS and Windows 10. Supports pen input from devices such as Wacom Tablets.

https://xournalpp.github.io

GNU General Public License v2.0

11.28k stars 803 forks source link

[Question] Cannot open remote files #1269

Open AlessandroW opened 5 years ago

AlessandroW commented 5 years ago

Affects versions :

OS: Arch Linux
Xournal++ 1.0.12

Describe the bug Cannot open remote files.

To Reproduce

Open Gnome-Control-Center
Log in to a Google-Drive account
Open a remote .xopp file

Expected behavior Usual workflow.

Screenshots of Problem

Why is this not possible?
Is it on the roadmap?

AlessandroW commented 5 years ago

Can someone add some information why it is not possible? If it is not too difficult maybe I could implement it.

LittleHuba commented 5 years ago

@andreasb242 Could you answer this?

andreasb242 commented 5 years ago

Xournal++ used first the standard ZLib API, not the GLib wrapper, and they don't support URLs, Gnome 2 returned the real URLs from Open Dialog, like smb://server/share/file.xoj, and this cannot be opened.

File reading / writing was completely refactored, so may this is no issue anymore. May also Gnome 3 handle this different.

Maybe only add the remote supported flag to the Open Dialog, and everything works, probably nobody has tried this since years ;-)

andreasb242 commented 5 years ago

XojOpenDlg.cpp

gtk_file_chooser_set_local_only(GTK_FILE_CHOOSER(dialog), true);

Here is the question, what is returned now? Theoretically there should always be a local path, e.g. if I mount an FTP, it ismounted local at: /run/user/<my-user-id, e.g. 1000>/gvfs/ftp:host=192.168.1.2,port=123

and this is a local mounted path, so if we can get this Path from Filechooser, it should work without changes of the file loading / writing, because we don't use GTK file API.

LittleHuba commented 5 years ago

The way to go is using GIO for this as mentioned in the documentation. Unfortunately the libraries required for the new fileformat are C libraries and therefore incapable of using GIO.

Only one solution comes to mind but this is really ugly: We could use GIO to download remote files to a local directory and then open the file with the normal routines. For saving we could also use this abstraction.

andreasb242 commented 5 years ago

For a Java Application I did simple a hack, and resolve a mountpoint, then you have a local path, and it's working. This should also be possible for this case.

embeddedt commented 4 years ago

There's a workaround I use on Ubuntu with several other Linux programs that also appears to work with Xournal++.

If you are always mounting the same network drive, you can create a symlink in an easy-to-access location (i.e. your desktop or home folder) that points to the drive's FUSE mount point.

networkdrive -> /run/user/<uid>/gvfs/smb-share:server=<server>,share=<share name>/

After that, you can open remote files using this path without an issue. Saving also works.

AlessandroW commented 4 years ago

Thanks, I created a symlink like you suggested:

google-drive -> /run/user/<uid>/gvfs/google-drive:host=gmail.com,user=<user-name>/

Things I noticed:

nautilus takes tens of seconds longer to load the same folder
folder have seemingly random names without file endings (hashed?)
based on the filesize I was able to identify the test xopp file
This time I could open the file.

So yes, the workaround does work. But the missing filenames and the long loading time makes it unusable. Did you experience similar issues?

embeddedt commented 4 years ago

But the missing filenames and the long loading time makes it unusable. Did you experience similar issues?

I'm using Samba. The filenames show up normally for me. It does take a bit longer to open folders, but not long enough to be a big deal (definitely not ten seconds longer).

Evidently this doesn't work as well for Google Drive.

nmendozam commented 4 years ago

I have the same behavior in gnome as @AlessandroW reports with the mentioned symbolic link workaround.

Febbe commented 4 years ago

This could be fixed already in v.1.1.0-dev

WillNilges commented 3 years ago

I'm mounting drives on my server over ssh and trying to load files from that. @Febbe how do you mean this is possible in v1.1.0-dev? Is there work to do on this or has it already been done?

Technius commented 3 years ago

I'm very confused about there is a limitation on opening remote files. We already depend on gio anyways, so we should be able to leverage gio's features to read/write files.

@LittleHuba: We could use GIO to download remote files to a local directory and then open the file with the normal routines. For saving we could also use this abstraction.

I'm not too familiar with gio, but a quick look at the API suggests that there's no need for workaround. We could make the file chooser return a URI and then call g_file_new_for_uri(), which supports file://, smb://, ftp://, ssh://, etc. URIs. There may be some slight caveats when authentication is required, but this should work out of the box for common use cases.

@WillNilges: how do you mean this is possible in v1.1.0-dev? Is there work to do on this or has it already been done?

I think @Febbe means that it is possible to implement but that no one has implemented it yet.

fbacani-ufop commented 3 years ago

Any news on this? I'm using the 1.0.20 Flatpak version, and I can't open or save at remote goggle-drive directories mounted via gnome "online-accounts"'s package.

The subfolder gvfs in /run/user/1001/ simply doesn't appear in Xournal++.

Thanks, Felipo

WillNilges commented 3 years ago

@Technius Ah, I see. Well, I'm taking my last final in about two days. After that, maybe I'll take a crack at it if nobody else has.

Technius commented 3 years ago

Any news on this? I'm using the 1.0.20 Flatpak version, and I can't open or save at remote goggle-drive directories mounted via gnome "online-accounts"'s package.

The subfolder gvfs in /run/user/1001/ simply doesn't appear in Xournal++.

This is a bug with our flatpak, please submit an issue here: https://github.com/flathub/com.github.xournalpp.xournalpp

Can you try running

flatpak override --talk-name='org.gtk.vfs.*' com.github.xournalpp.xournalpp

fbacani-ufop commented 3 years ago

@Technius Ah, I see. Well, I'm taking my last final in about two days. After that, maybe I'll take a crack at it if nobody else has.

Actually, it worked when using the stable PPA version (the snap also didn't worked). Thanks @WillNilges and @Technius.

This is a bug with our flatpak, please submit an issue here: https://github.com/flathub/com.github.xournalpp.xournalpp

@Technius I didn't knew that. Thanks and sorry for the mistake.

By the way, the suggested command flatpak override --talk-name='org.gtk.vfs.*' com.github.xournalpp.xournalpp didn't worked.

Febbe commented 3 years ago

@WillNilges Reading and writing files from a mounted device should work with v.1.1.0~dev without a problem.

Currently we don't support URI files with another scheme than file:// and honestly I don't see much benefit in supporting them. Nearly every other scheme can only be used to read only. And they are suspect of change which is a bad choice for example for a PDF background.

WillNilges commented 3 years ago

I see, I'll test this out tonight and see if it can do what I think it can. If so, then when will this feature get merged? Because this would be LIT to have.

Technius commented 3 years ago

I see, I'll test this out tonight and see if it can do what I think it can. If so, then when will this feature get merged? Because this would be LIT to have.

You could try mounting the remote folder using gvfs first (e.g. through your file manager). It should then be accessible in Xournal++ through the file chooser (in Nautilus, it's under Other Locations > Network). I tried this with a PDF on a server I have and I can annotate/load it successfully.

If this works correctly, I think we can just close this issue.