From kde-usability  Thu Aug 26 15:17:43 2004
From: "Daniel Molina" <dmolina () amnet ! co ! cr>
Date: Thu, 26 Aug 2004 15:17:43 +0000
To: kde-usability
Subject: Changing copying behavior / General Action-Queue framework??
Message-Id: <web-3814551 () amnet ! co ! cr>
X-MARC-Message: https://marc.info/?l=kde-usability&m=109353348713483

Hello,
Last night I was copying some code from my Desktop PC to 
my Laptop.  It was like 600MB of files being copied over a 
802.11b connection,  so it would take a while.  I left and 
after 1 hour I returned to see that somewhere around the 
20MB there was a file that already existed in my Laptop, 
so Koqueror greeted me with the dialog "do you want to 
overwrite ....".  One hour worth of work lost due that.

I start thinking about a solution for it.   The other 
580MB could be copied without major concerns,  so why 
Konqueror did not do it?   Because (I assume since I 
haven't seen the code) it uses a static queue, one file 
after another, one action after another.  What a waste!!!

Why not implementing a more robust structure for queuing 
work and actions?  If I want to copy 1000 files, this can 
be treated as 1000 operations with no dependency between 
them, so if 10th operation requieres user intervention it 
will be moved to another queue and other actions will 
continue to be executed.  Think something like the D/l 
manager of Mozilla.  When I start the copying of files, a 
dialog with a progress bar will appear showing current 
progress.  After a while, if some file copying requires 
user interaction, another item will be added below, with a 
message or something ... once user provides information 
file will be requeued.    

IMHO, this will greatly enhace usability, as operations 
that can be completed would be completed.  Extending this 
to a general framework, think of general actions instead 
of just file copying.   I would be able to queue something 
like several FTO transfers and if one fails, the other 
will execute.  If I'm transfering RPMs I would be able to 
queue also an installation action, so here We can think of 
dependant actions ... if transfer of a RPM from FTP works, 
then its Installation begins, if it failed (pwd required, 
etc) the whole tree of dependant actions would be queued, 
but the rest will be executed.  

For the newbie may be general actions would be too 
complex, but I'm sure that for general file actions that 
can be blocked by write permissions or other situations 
this will save time & resources.



May be this dialog sketch helps on visualizing the idea:

+-------------------------------------------+
|                                           |
| Copying TARGET6.SH  75%  |........  |     |
|                                           |
+-------------------------------------------+
| Pending:                                  |
|  +-------------------------------------+  |
|  | Target3.SH already exists.        | |  |
|  | Overwrite?   [Yes] [No]           |-|  |
|  |-----------------------------------| |  |
|  | Target1.SH already exists.        |-|  |
|  | Overwrite?   [Yes] [No]           | |  |
|  |-----------------------------------| |  |
|  | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\  | |  |
|  +-------------------------------------+  |
|                                           |
|                         [ OK ] [ Cancel ] |
+-------------------------------------------+



Regards,

Daniel Molina
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability