GNOME Bugzilla – Bug 501542
switch to gio/gvfs
Last modified: 2008-04-14 17:21:03 UTC
nothing else to say. i haven't found any related bug, but if this has been already made or there has been a bug report for this.
Since nautilus does not use gnome-vfs anymore, the nautilus extension fails to build. I've committed a work-around. 2008-01-08 Wouter Bolsterlee <wbolster@svn.gnome.org> * configure.in: Add gnome-vfs libs for the nautilus extension since they're not automatically pulled in with Nautilus anymore (Nautilus uses GIO now). The real fix would of course be to convert the code to GIO, but this workaround at least fixes the build for now. See also bug #501542. Confirming this bug, gnome-vfs will be deprecated soonish.
Created attachment 104378 [details] [review] file roller nautilus extension port Here's a port of file roller's nautilus extension to GIO. All functionality works here with a brief amount of testing. The error reporting might be a bit bogus though. I can look at porting the rest of file roller, but this restores that functionality for now.
Created attachment 104472 [details] [review] oops, slightly better version little bit of an improvement.
The current gnome-vfs based extension leads to very bad performance when working with files on network mounts. I assume this is because the extension needs to "mount" the location again in order to get filetype and attributes etc. You can see how bad this is on an SFTP mount: try to shift select a lot of files. Depending on the latency etc, this operation will take ages and even blocks nautilus. Please disable the extension as long as the GIO port is not done.
we probably want to find an improvement here within the 2.22.x timeframe, e.g. for 2.22.1.
Created attachment 106989 [details] [review] Another take on the patch So, at the moment the extension is totally on crack by doing sync IO inside the main loop. It also does stat the parent for every file in the list. This list changes every time the selection in nautilus changes. So we are doing lots of sync stat calls from the mainloop. This is especially bad for remote locations since that will slow down the whole of nautilus. We MUST NOT do that. Trying to find out if the parent is writable itself is sane, just not the way we do it now. Nautilus actually already has stat'ed the parent and already knows if the parent is writeable or not the functions are just not (yet) exposed by the extension API. So for now I think the most sane thing to do is just *assume* the parent is writable and always show the "Extract here" context menu entry. If we are wrong and we lie about we will catch that error when the user really tries to extract the archive. I think this is not too bad and in real life probably very not very often the case.
If people agree that my take is the best thing to do for now we should depend this bug on bug #521612.
Created attachment 107452 [details] [review] patch This patch depends on the changes in bug #521612, and does what Christian suggests in the FIXME comment on his patch.
I reviewed Cosimo's patch (note I am not a file-roller guy, but a gvfs maintainer) and it looks good. Once bug #521612 is fixed I suggest that patch to be applied to file-roller. Thanks Cosimo.
Created attachment 107918 [details] (unfinished) First stab at complete gio port. Hi, I've made an attempt at porting f-r to gio which I thought would be best to post since I'm kind of stalled at the moment. It's unfinished and not heavily tested (but seems to work). Hopefully someone has some use for the changes made so far. I've tracked my changes with git and the attached file is a "git log -p upstream..gioport" (where upstream = v2.22.0). This means the file contains a set of patches, which you probably want to start reading from the bottom up.
Andreas, thanks for the patch.
I just checked out file-roller head. Guys, did you actually read any of the stuff I have written. Paolo? Andreas? Anyone? Ok, I really don't want to sounde rude but maybe I was not clear enough: PLEASE NEVER DO USE SYNC IO. You're code in nautilus_fr_get_file_items () is running inside nautilus' main loop. DON'T DO SYNC IO. Also you are stating the parent again and again even if it is the same parent. Why on earth do you ignore me? Your badly written extensions caused hangs for a lot of people and we got bug reports for that in every distribution. I patched that file in the way I did it for a good reason.
Created attachment 108621 [details] [review] Patch for stable Ok, I have patched the nautilus extension so distributions can pick it up for 2.22.1 This patch utilizes the new functions in libnautilus-extension thus requiring nautilus 2.22.1. NO sync io is done in that patch. It also restores all the functionality that was disabled due to missing nautilus features. File-roller maintainers: I really urge you to use that code for the nautilus extension also in trunk. Kthxbye
Created attachment 108623 [details] [review] Updated patch against stable (gome-2-22) Don't mix tabs and spaces. Sorry.
I'm sorry if I've upset you, Christian. Here's my explanation which might help people understand what happened: My effort was started before any of you had comments on this bug, and the nautilus extension was the absolute first thing I touched. I also think I pretty clearly stated that my patch was unfinished and incomplete, only lightly tested which means high possibility of bugs. Please don't be offended by me not having motivation to finish what I started. I didn't ignore you, I just didn't have time and motivation to update my patchset with stuff that had appeared between my changes and when I actually posted it here. That's probably what confused Paolo and made him miss your input.... I'm sorry.
Andreas, eh no worries, I actually felt bad for being to harsh after I calmed down. I am just too emotional sometimes. Sorry. Let's just hope trunk gets fixed and maybe my patch can even be applied to 2.22.1.
patch applied to the gnome-2-22 branch
I changed the required nautilus version to 2.22.2, because according to the NEWS file that's version that adds the required functions.
so is that patch included in file-roller 2.22.1 or not?
the 2.22.2 tarball contains the patch, thank you and sorry for the delay.
so the patch has been committed both to trunk and to gnome-2-22? i assume it has not completely removed the dependency on gnome-vfs? just wondering whether http://live.gnome.org/GioPort needs an update.
still not committed to trunk.
The gio port is complete now, though this doesn't mean that there is no bug caused by the port :)