Comments on: File operations in nautilus-gio and adventures in the land of PolicyKit

By: Prakash Jose Kokkattu

Prakash Jose Kokkattu — Thu, 13 Dec 2007 08:33:21 +0000

thanks for this initiative.I likes Nautilus FM.please make it load faster

By: Vadim P.

Vadim P. — Tue, 27 Nov 2007 13:50:36 +0000

Thank you so much for that policykit thing!

By: amano

amano — Mon, 26 Nov 2007 15:01:03 +0000

*woot*
Can’t wait for this sudo button on the error dialog. I hope that this will make it into 2.22. A feature that many have called for: http://ubuntuforums.org/showthread.php?t=588243

Great that these things seem to be technically possible right now.

By: alexl

alexl — Mon, 26 Nov 2007 08:03:54 +0000

A Pause button seems like an interesting idea too

By: alex r

alex r — Sun, 25 Nov 2007 18:01:03 +0000

On the subject of a cancel button: the dialog really needs a pause button. That way, if you are uploading a large file over a slow connection, you can temporarily pause it, do some useful work, and then start it going again. Pausing might not make sense for local file transfers, but for large transfers over the network, it is absolutely essential.

By: pirast

pirast — Sun, 25 Nov 2007 17:36:44 +0000

i had that idea some time ago, also see http://bugzilla.gnome.org/show_bug.cgi?id=474261

By: Frej Soya

Frej Soya — Sat, 24 Nov 2007 20:54:49 +0000

Isn’t the transfer status (the small bar) in the WM nautilus folder icon good enough?
Instead of having a seperate ‘progress notification icon+window’ then it’s just the folder icon (in top corner) that shows progress?

Just trying to keep stuff out of notification area. It’s not that important

By: alexl

alexl — Sat, 24 Nov 2007 09:59:56 +0000

Björn: Long term, yes, since we can drop a bunch of libraries, etc.

However, short-term we still link to these libraries via some dependencies (like libgnomeui). As project ridlrey continues we’ll soon reach a point where we can dump a lot of crap though.

By: Mathias Hasselmann

Mathias Hasselmann — Sat, 24 Nov 2007 08:59:53 +0000

Oh, seems Xav wrote at the same time like me, so I didn’t see him mentioning the psychological aspect justify queue also for network transfers. Seems the queue heuristic for network transfers needs some more finetuning yet. Also like the local queue heuristic could be tuned (many small vs. few large files). So I guess in terms of code the queue policy should get some good encapsulation for better fine tuning over the time.

By: Mathias Hasselmann

Mathias Hasselmann — Sat, 24 Nov 2007 08:55:48 +0000

> Queued transfers could be added without *that* much work I guess. I’m a little surprised that people see them as so important though. What do you want them for?

File transfers only are fast, when you avoid disk seeks. That’s somewhat true for hard-disk transfers, but even more true, when copying data from CD/DVD. Interestingly the problem doesn’t show up in your demo. Probably since you copy many small files. Well, but when copying large files I’ve observed overall throughput dropping to 50% and less on harddisks, but more dramatically to just 10% on optical media for just copying two large files in parallel.

So the queue-rule should go like this: Only one active file-transfer per physical device. Guess fetching from distant HTTP and (S)FTP servers doesn’t fall under this rule, as for such transfers network bandwidth, not disk seek time is the limiting factor.