Hail sailors! Yesterday, came to me a mind boggling thing, while doing my personal music selection to be copied to my N85, i have stopped with a problem.
My N85 can handle lot music (8GB). And I wish to fill out, not only with a single band or single albun, I wish to copy many files scattered in a bunch of directories (I have a 180GB repository). Since I cannot have 2 group of files in copy clipboard at same time, I have to start a copy, and change dirs, and start another copy, often this copies happens simultaneously, and this works likes a snow ball, going to a point that we call (in system tunning) saturation point, when youre have more simultaneous file operations than your I/O device can handle, raising all queues (VFS, FS, Bus, Card, Disk, Head), and dropping our average througput (in theory sata can handle 2gb/s), but with 10 simultaneous file operations, no more than 10kb/s can be reached, cause the disk head need to move A LOT. Ok, I can copy one pack of files, wait the copy finish, copy another pack, and goes on, think to fill a 8gb disk will take a while (and I will lost all my busy day in this lovely task). Since Im not satisfied with the second option, I thought, why not write something to handle that? And I did. I wrote a simple nautilus script with a simple interface in python-gtk (i can share it, not aproblem) to do the following: 1. Nautilus script "tag" the files to be queued with a file name simple redirection to a control file 2. this control file stores all files names that I want copy, 3. with a simple pygtk interface, I open this file in grid where I can START, STOP, and schedule the copy, then I do my "queue copy" with basic filesystem operations This task works fine, but isnt a elegant solution, then im not satisfied with that too. Then I came to #nautilus and #gnome channels and asked for guidance in how to handle that in a more gnomewise way. What Im thinking: In first view I will remove the interface from user. In first glance users copy from same SOURCE_DEVICE x DESTINATION_DEVICE should NOT be done at same time, they should be queued, in a overall this drops the i/o througput to floor, doing 2 simultaneous copies at same time in same device is slower than do one copy then another. Raising the number of simultaneous copies will make this time raise in a exponential way. And makes the system locks, since concurrence to load applications virtual images from disk, and swap operations will be on disk queue. BUT, this point of can be too much radical for some ppl here, and I though to add a shortcut to point my will to do the queue not direct copy, example, dragging and dropping will copy, drag and drop with ALT key pressed makes a queue copy (of course the shortcut can be changed). Or I can set in a gconf key, flag 0 no queue at all, flag 1 optional queueing (with shortcuts or something else), flat 2 (always queueing, shortcut will disable the queue). Of course creation of icons to identify that copy will be queued or not should be added for sake of user. Adding more features, I thought in change the default gnome file operations window (that opens when we do file operations), the user should be able to see the queueing status, be enable to pause, restart, cancel, and start file operation or schedule the operation to sometime in future. I want to discuss some things here: 1. Is that a good ideia? or not? 2. Someone else is already planning on do that? or is already doing that? 3. What is the more gnomewise way to do that? 4. Where can I read more about the things to do that (i have a fair knowledge in C and Python) 5. Any changes to make this a damn good ideia will be welcome. IMHO, I think that is a must to any user interface, in today computers, everyone has a lot of disk (we talking about 1TB in a single desktop computer), doing things as hand made backups, or mp3 file copy, of simple file system organization in a environment where all file operations happens in same time, makes the system unusable. That is it. Any ideas are welcome. Im willing to write that. -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list
