This is an absolute must-have for me too, especially because gThumb also doesn't threat mounted NFS shares correctly, which I tried as a work-around for this VFS issue. gThumb is absolutely unusable in a network environment this way!

Tom

*** Bug 308860 has been marked as a duplicate of this bug. ***

*** Bug 300808 has been marked as a duplicate of this bug. ***

Fileroller has the same problem: bug 152920.

Bumping version up to 2.9.x - still an issue. 

- Mike

*** Bug 397308 has been marked as a duplicate of this bug. ***

I´ve seen that internally GnomeVFS is used, why doesn´t it work yet then?

Philipp,

A quick test shows that I can open VFS URIs (like smb://....) if I select "Other..." in the pop-up folder bar, and enter the URI manually.

It doesn't work if I pass the URI as a command line parameter, however (gthumb smb://....).

So... VFS is semi-supported. I suggest taking a look at src/main.c, and see how command line arguments are being handled. The code is probably assuming simple file names, rather than VFS URIs.

- Mike

For me this doesn´t work, too. It just opens my homefolder. Instead, I made an additional gtk_file_chooser_set_local_only() call for the "Open location" filechooser. Now I can successfully open and browse remote directories, but images they contain are just not displayed (gthumb uses the default thumbnail and if I open them, I just get an empty image)

Yes, lots of strange things seem to happen.

I can browse remote directories using the "Other..." tool, but I can never load images.

Some smb:// URIs do display thumbnails, but some don't. ssh:// ones never do. http:// doesn't work at all.

So I guess the VFS code is a mess at the moment.

Are you using svn trunk? I can review/commit patches for you, if you are in a position to write some.

- Mike

Yes, I´m using SVN trunk. But until I figured out what exactly is messed up (because it´s REALLY strange by now), making patches won´t make much sense. I´ll let you know as soon as I find something out.

Philipp,

The basic problem is probably this: 

gThumb uses gdk_pixbuf_new_from_file to load the images, and gdk_pixbuf_new_from_file doesn't seem to support gnome_vfs! It just takes an "ordinary" file name.

http://developer.gnome.org/doc/API/2.4/gdk-pixbuf/gdk-pixbuf-file-loading.html

I'm not sure what to do about that.


- Mike

Ah ha! We need:

gnome_gdk_pixbuf_new_from_uri

http://developer.gnome.org/doc/API/2.2/libgnomeui/libgnomeui-gnome-vfs-util.html#gnome-gdk-pixbuf-new-from-uri

- Mike

Created attachment 80535 [details] [review]
Patch to use gnome_gdk_pixbuf_new_from_uri in image_loader

Here is a quick-and-dirty mini-patch that allows the image loader to open VFS URIs (using the "Other..." tool). I tested it using smb:// and ssh://, and it seemed to work, except for the occasional assertion error like:

** (gthumb:19275): CRITICAL **: do_load_internal: assertion `g_path_is_absolute (path)' failed

You can "grep gdk_pixbuf_.*_from_file */*.c" to see what needs to be changed, at a minimum (plus the argument parsing in src/main.c:initialize_data).

- Mike

libgnomeui is going to be deprecated, so I think we should reimplement that function locally (file-utils.c seems a good place)

For performance reasons I'd use gdk_pixbuf_new_from_file for local uris (uris with a file: method) and gdk_pixbuf_loader_write for remote ones

Paolo,

Just an idea: do you think we can borrow anything from gegl or a different library, which would get us HDR and/or RAW support at the same time (bug 312896 and bug 145564)?

- Mike

it depends on how much code have to be imported, if the code is too big I don't think it's worth it

To do:

- copy gnome_gdk_pixbuf_new_from_uri equivalent into file-utils.c
    - later: two loader methods, local/remote, for performance?
    - add assertions to check for URI format

- replace gdk_pixbuf_new_from_file instances

- modify do_load_internal to accept full URIs
    - add assertions to check for URI format

- modify main.c to accept URI arguments


- Mike

also:

- resolve_all_symlinks is broken for VFS URIs

Created attachment 80791 [details] [review]
Rough patch to add vfs support

This is a rough patch that adds VFS support through the "Other..." folder function. I've tested it with ssh:// URIs, and it loads both the thumbnails and the images. It is not ready for svn commit.

Issues: 
- it doesn't show GIFs on VFS
- the "animated" pixbuf functions aren't VFS enabled yet
- it doesn't accept command-line URIs yet
- resolve_all_symlinks has been modified, but not tested
- http:// URIs don't work - I don't know why. Anybody?
- I am using gnome_gdk_pixbuf_new_from_uri from libgnomeui. It should be re-implemented locally.
- I haven't added any gtk_file_chooser_set_local_only calls - where do they go?
- I imagine I've broken other things...

Notes:
- Two new functions have been added to file-utils.c
     - gth_pixbuf_new_from_uri
          - switches between gdk_pixbuf_new_from_file (local files)
            and gnome_gdk_pixbuf_new_from_uri (remote files)
     - gth_pixbuf_animation_new_from_uri
          - just returns gdk_pixbuf_animation_new_from_file
            for now. Rewrite to support VFS.

Feedback would be useful...

- Mike

I think the only big issue is saving images on a remote location, the only solution that comes to my mind is to save it in a temp directory and copy it with gnome_vfs_xfer to the destination.


> it doesn't show GIFs on VFS

if the location is remote we can simply use gth_pixbuf_new_from_uri and load the gif as a static image, it's sub-optiomal but at least you can view something.

> the "animated" pixbuf functions aren't VFS enabled yet

using a temp file can fix this issue as well, if the gif is remote copy it in a temp dir with gnome_vfs_xfer and then load it with gdk_pixbuf_animation_new_from_file

...

> I haven't added any gtk_file_chooser_set_local_only calls - where do they go?

After creating the dialog and before showing it.

> I imagine I've broken other things...

why don't you make a svn branch? this way it'll be easier to test the patch.

Paolo,

Thanks, I hadn't thought about file saving yet.

I'll make a "vfs" branch in a while.

- Mike

A "vfs-testing" branch has been added.

- Mike

Note to self:

Check all gtk_file_chooser_dialog_new instances.

- Mike

More todos:

- check copy/duplicate/rename functions
- implement tmpdir for animated gifs

The vfs-testing branch works for smb:// and ssh://, but something odd is going on with the authentication dialogs - they aren't always offered.

For instance, if you view a ssh:// location and close gthumb, then re-start, it tries to go back to that location but fails with an authentication error. It doesn't offer an authentication dialog. Something to look into...

- Mike

I just noticed these console errors:

connection_message_func(): Callback
CALLBACK: fill-authentication!!!

- Mike

The authentication problems were fixed with:

#include <libgnomeui/gnome-authentication-manager.h>
gnome_authentication_manager_init ();

in src/main.c.

- Mike

svn rev 1288 can launch single VFS files/directories from the command line now.

Multiple files (= command line catalog) do not work yet.

- Mike

Paolo,

I can launch VFS files from the command line now, but if I browse to the remote VFS file location using Nautilus and use the "open with" right-click function it doesn't work.

The filename doesn't seem to be passed as an argument into src/main.c:initialize_data - it's being filtered out somewhere at a higher level. (If I use "open with" on a local filesystem folder, it works OK).

Any ideas where the problem might be?

- Mike

Just to clarify: if I use "open with" on a remote Nautilus VFS file, the gthumb argc = 0.

- Mike

Never mind, I figured it out. Use "Exec=gthumb %U" in gthumb.desktop.

- Mike

Catalog support is broken currently in vfs-testing.

- Mike

Catalog support has been fixed in vfs-testing branch.

Done:

- VFS browsing with "Other..." and Ctrl+L works
- VFS args on command line work, except if shell globs are present
- video thumbnailing and playing seems to work (bug 134366)

To do:

- should we manually process command line VFS shell globs?*
- fix remote animated gif display
- file saving, exporting, copying, renaming: not tested yet
- symlink handling: not tested yet


* I'm not sure what to do about this, if anything. Is it worth re-implementing the shell functions for vfs? Is there a handy function to do that? Suggestions?

- Mike

Animated gifs work now.

No one else seems to support VFS "shell globs", so we'll forget about that.

To do:

- what happens in the folder browser when you go to the root of a remote URI?
- file saving, exporting, copying, renaming: not tested yet
- symlink handling: not tested yet

Some functions that use "fopen" (and thus lack VFS support):

libgthumb/jpegutils/jpeg-data.c: 
    jpeg_data_load_file
    jpeg_data_save_file

libgthumb/jpegutils/jpegtran.c:
    jpegtran

libgthumb/pixbuf-utils.c:
    _gdk_pixbuf_savev
    _gdk_pixbuf_save_as_jpeg
    _gdk_pixbuf_save_as_tiff
    _gdk_pixbuf_save_as_tga

libgthumb/comments.c:
    save_iptc_data

src/catalog-web-exporter.c: 
    save_html_image_cb
    save_html_index_cb
    parse_theme_files

- Mike

I'm trying to add VFS save/edit support, but I've run into some trouble and could use suggestions.

The problem is that GnomeVFSFileInfo reports these fields properly for local files:

GNOME_VFS_PERM_ACCESS_READABLE
GNOME_VFS_PERM_ACCESS_WRITABLE
GNOME_VFS_PERM_ACCESS_EXECUTABLE

but not for remote (ssh://, smb://) locations. Remote locations seem to report zero for each of the above permissions. (The other permissions, like GNOME_VFS_PERM_USER_READ or GNOME_VFS_PERM_GROUP_WRITE are reported correctly.)

gthumb checks these bits to see if we can edit files in a given folder.

Is there a known problem with these bits for remote URIs?

svn rev 1305 of vfs-testing prints out the permission bits to the console, for debugging. See libgthumb/file-utils.c: check_permissions.

- Mike

VFS saving seems to be fraught with peril. Some bugs to study:

Bug 40644 – Untrustable uid & gid in file info
Bug 155866 – Respect GNOME_VFS_FILE_INFO_FIELDS_IDS
Bug 169726 – Connect to sever (SSH) file permissions are wrong (cannot save files)
Bug 110191 – Gedit can't save directly to a remote file (gnome-vfs write support)

- Mike

Do we really need to check directory permissions beforehand, or should we just attempt to overwrite the file as required and report an error if it fails?

- Mike

I think simply trying it should be enough for now...

Regards,
pkerling

OK, I've re-written src/dlg-jpegtran.c:apply_transformation to use local caching of remote VFS files, without directory-permission checks. So jpeg physical rotations can be done on VFS files now (svn rev 1306, vfs-testing branch).

Some observed issues:

1. Comments aren't being loaded from remote files (minor)

2. Exif tags aren't being loaded from remote files (major)

3. Permissions-related error messages from the "mv" line in src/rotation-utils.c:apply_transformation_jpeg are being reported to the console, rather than through gthumb. This should be done more elegantly. This is only an issue for local files, because the calling routine (apply_transformation) catches VFS problems before it. (minor)

- Mike

I've tidied up the rotation error reporting, so that is fine.

The exif tag issue is a bit worrisome. libexif doesn't support gnomevfs, so if we want to read exif tags we have to copy the whole file to a temp dir, which will be really slow if we have to do it repeatedly.

Maybe the preloaders should copy remote files to a cache, and we check the cache before rotating, or reading exif tags, etc. That adds a whole layer of complexity to reads and writes though, and will use up a lot of disk space locally (temporarily).

Should we opt for speed or simplicity here? Do you have any preference, Paolo?

- Mike

I've added remote XML comment reading support.

XML comment writing, iptc read/write, and Exif read/write are next on the list.

For now, I'm just making temporary local copies of files when we need to access remote files for functions that don't support VFS natively. I'm not going to try longer-term file caching. Image editing is never going to work well over DSL or slower links anyways...

- Mike

Paolo,

VFS support is nearing completion. I have implemented a local cache for remote files after all.

If I get some time this weekend, I hope to wrap up the remaining loose ends and merge the vfs-testing branch back into the trunk. Is that OK with you, or do you want them kept separate for a while?

- Mike

OK, the vfs-testing branch is "feature complete". You can browse VFS folders and edit remote images. (Also, video thumbnailing, video launch, and RAW photo thumbnailing using libopenraw, are now implemented.)

I am aware of one crasher bug (bug 403932), which I haven't looked at in detail yet.

Testers welcome!

- Mike

Fixed the crasher bug. I am unaware of any remaining VFS issues.

I will merge vfs-testing into trunk tomorrow, unless I hear otherwise from Paolo.

If you install the vfs-enabled versions, you might need to change your gthumb.desktop file(s) to read:

Exec=gthumb %U

instead of

Exec=gthumb %F

to allow right-clicking launching of VFS URIs from Nautilus.

I'm not sure how changes to gthumb.desktop are supposed to propagate - it is correct in svn data/gthumb.desktop.in.

- Mike

It´ll be merged by intltool to data/gthumb.desktop automatically when you update svn and run make.

Hi Mike,

I've tried the vfs-testing branch browsing a ssh folder, and it sometimes dies suddenly.  Looking at the code I suspect this is due to the complexity of the functions called in the image_loader thread, it's likely that some of that functions are not thread safe.  

I think the image_loader thread must be used only to load the local image with the gdk_pixbuf_... function, which is not asynchronous, while all of the other functionalities (such as coping the remote image locally, etc.) can be done in the main thread.

(In reply to comment #47)
> It´ll be merged by intltool to data/gthumb.desktop automatically when you
> update svn and run make.

But do gthumb.desktop files in the user's home directory (e.g., /home/mjc/Desktop/gthumb.desktop) get updated after a "make install"? I don't think they do...

- Mike

Hmm, I suppose only the "normal" ones in the prefix (e.g. /usr(/local)/applications) get updated. But luckily they´re (nearly) the only ones that matter for e.g. nautilus, the user´s local copy on his desktop doesn´t change the way nautilus runs programmes, at least I hope so...

Paolo,

I haven't seen any crashes like that in my VFS tests using ssh and smb. (The worst I have seen is the extremely slow loading of large folders, presumably because GnomeVFS is making a new ssh connection every single time it reads file info (size, mtime) - but I'm not sure about that. But that is just an annoying delay, not a crash.)

Do you (or anyone else here) think that you can patch the thread problem? I'm not familiar with thread coding, and I don't understand the issues. Someone other than me will have to fix that.

- Mike

Paolo,

It might be worth experimenting with reverting my stack-size patch (bug 310749), to see if that affects vfs stability at all.

- Mike

I removed the prune_cache step from obtain_local_file. That might not have been thread-safe, and it was not really necessary since the cache is pruned at start-up.

- Mike

I have also stopped using f_load_scaled_jpeg on remote jpegs, even though it supports VFS URIs. A local cache copy is made now. This is actually much faster for typical photos.

Paolo, when you have a moment, could you test the branch again to see if it still dies on you?

- Mike

(In reply to comment #54)
> I have also stopped using f_load_scaled_jpeg on remote jpegs, even though it
> supports VFS URIs. A local cache copy is made now. This is actually much faster
> for typical photos.
> 
> Paolo, when you have a moment, could you test the branch again to see if it
> still dies on you?

Yes it still does.  To reproduce the bug I just scroll the image list while the thumbnails are loaded, it dies every time.  

That's odd. I can't reproduce that problem.

- Mike

Paolo,

I will merge your mime-type changes in from trunk.

- Mike

ok, maybe it's a totally unrelated problem.  I think it's a good idea to merge the vfs-testing branch with trunk now, then we will see what to do...

I've noticed that the directory I load with ssh contains some svg images that make gthumb die even when opened locally, even eog dies when I try to open the image with it !  maybe this is a bug in librsvg or whaterver is used to load svg images, so I'd say it's ok to merge the vfs branch :)

That's great news; the crashes aren't all my fault! :-)

Anyway, your mime-type changes cause these compiler warnings:

file-data.c: In function 'file_data_update':
file-data.c:109: warning: passing argument 1 of 'g_free' discards qualifiers from pointer target type
gth-file-list.c: In function 'load_new_list':
gth-file-list.c:1036: warning: passing argument 3 of 'g_hash_table_insert' discards qualifiers from pointer target type

- Mike

VFS support is in svn trunk now, and should appear in the next release.

- Mike