So back in the swing of things. Finishing up the xml config reading code and hooking it into the main task queue manager so that it can create the various tasks and queues on command.
Stuff that's working/unit tested:
* Reading config from xml file
* Individual task execution (so extract already works, at least in a unit testing environment)
To Do:
* Hook up the gui listQ to taskQ actions (like pause, delete, remove, up and down) and customize the display based on task type (BIG)
* Do the task threading execution and locking (SMALL)
Stuff that may wait for alpha/beta 2 so I can check in some code finally:
* Automated xml config modification using a tree control(so do it by hand for now) (MEDIUM)
* ACE,ZIP support (SMALL)
* Some more esoteric options (MEDIUM)
* Progress bars (MEDIUM depending on how I do it)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not much time to do it now and it's hard to describe it when it has a lot to do with the GUI.
Basically, I was hoping the finished product would look like an expandable tree where actions are dependant on the success of failure of actions higher in the tree/hierarchy.
This will look sort of messed up on this board but this is a crude ascii representation:
A - Task 1 < top of the tree -- no dependancies>
|
+-- B - Task 2 <dependant on task 1's scuccess>
+-- C - Task 3 <dependant on task 1's scuccess>
+ -- Task 4 <dependant on both task 1's scuccess and task 3's success>
Being able to move things in and out of the task list in real-time would be important.
Another thing would be a right click to a folder to activate a sort of catch-all function which would automatically load a user-definable series of events into the queue.
For instance, an options menu would allow me to decide if I would like to delete par2 files after a successful fix, delete rar files after a successful extraction to the default extraction path, keep par2 history in memory or always do a clean check, look for the first X amount of par2 files in the folder or all of them, ect...
Then when I right click on a folder it would queue up something like this:
- CHECK all par2 files in the directory
- DELETE all par2 files that had a 'Repair not needed' message
- UNRAR all RAR files to the default dir
- DELETE all RAR files after successful extration
Then the same would happen to all par2/rar files in the folder.
Well, that's still not all of it but I'll post more later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is an extract task, and a repair task.
There is a repair/extract queue.
All tasks have a 'delete sources' options, which for Repair would be all (.vol*.par2, but not the original par2 (could make it optionally delete this one too)), and for Extract would be whatever files we discovered belong to the volume set (ace, c01, ...; rar, r01, r02...) during extraction.
So I hadn't thought about doing a folder level 'do something to all par2's in this directory'. It shouldn't be too hard to implement at least some of the functionality you are talking about. Simply when the right context target is a folder it can list Move, Copy, (Zip at some point), and then repair all par2's and/or extract all archives. It would just need to find all of the archives and then extract them to the chosen destination.
I'll have to figure out how I'll represent that in the config.xml but shouldn't be too hard. As it is already, if a single task repair or extract task contains a list of files, it will dedupe the files so that only one per par2 and rar volume set remain, and then creates a sub task for each one.
Keeping track of results after they are out of the queue (like in your 'DELETE all par2 files that had a 'Repair not needed' message' idea) is probably out of the scope of things at this point, as it would require a lot of thought.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Keeping track of results after they are out of the
>queue (like in your 'DELETE all par2 files that had a
Well, y'see, that would be the crux of the plan. For something like this to work, you would HAVE to know of a way of checking whether a task succeeded or failed for child processes to initiate.
You can't UNRAR a bunch of files unless all files are deemed OK.
Likewise, it would be prudent to stop the queue if an extraction process to the default drive becomes full. You would have to figure a way of looking for that error msg from Winrar.
I think I'm just misreading this. It's been a long ass day for me. <insert appropriate emoticon here>
>'Repair not needed' message' idea) is probably out of
>the scope of things at this point, as it would require a
>lot of thought.
Currently in QuickPar v.9, an option exists for the following:
- Delete Damaged Files after Repair
- Delete PAR2 files after Repair
- Send files to Recycle Bin
I just thought it would be cool if shellqueue had something similar
>So I hadn't thought about doing a folder level 'do >something to all par2's in this directory'
I'm basically describing some sort of shell integration the same way WINRAR allows users to do:
- Add to archive
- Add to '<CurrentFolderName>'.rar
- Compress and email
Similarly, it would be freaking sweet if this proggy would have similar characteristics where a right-click would show one or a few options (in a cascaded context menu).
If it's just one option, then something like:
- ShellQueue: Queue-It
I'm just throwing these out there. They don't have to stick. They're just suggestions that I think would make it easier to use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
XQs does not use WinRAR.exe, it uses the Unrar.dll directly. As it will UnAce.dll and zlib(zip).
XQs has an (umimplemented at this point) option UseRecycleBin for deletion action types.
XQs will not be able to do anything besides determine success or failure for repair until a par3.dll is released, as there is no way to get this information from par2cmdline currently, unless I hack my own par2.exe and release it as well. Ideally, in the fututre, before repairing XQs will check to see which files are damaged and/or missing. If it's only .nfo and .sfv, then XQs will not repair. Delete Par2s after a successful repair will be supported.
XQs was originally planned as ONLY a Windows Shell Extension (Right Click Context Menu sub menu) in explorer, so yes this will be supported. The first alpha won't focus on that though, but on the Directory Opus overloading of drag and drop. So shift drag and drop will launch exqueues from the Directory Opus version of Explorer, causing files to be moved, copied, repaired, extracted, repaired then extracted, etc. depending on how you have it configured.
So as it is now, the expected 'cascaded context menu support' is as follows: A Base ExQueues Item at the root level (with copy/paste/send to, etc). Then, depending on the file type(s) that are selected (and your settings), options such as move, copy, repair, extract, repair then extract, join, etc. will be listed. Then under each of these (say extract), a list of default destinations will be displayed (c:\My Document, <Here>, <Choose Destination from Dialog>, ./<archive name>, etc.) all chosen by you in the configuration settings.
Okay so 'Keeping track of results after they are out of the queue' meant to me:
You tell XQs to do something(right click/ d&d). It finishes. You tell it to do something else(right click/d&d): XQs will have no knowledge of the result of the first action, besides having logged that information for user validation.
However, the first 'telling XQs to do something' could have been "repair, then if successl delete par2s, then if success extract, then if success delete rars".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm getting pretty psyched. Everything seems to be coming together pretty rapidly. I currently have the DDE support functional.
So a shift-drag and drop in Directory Opus will launch ExQueues if necessary, then pass the destination and the files to ExQueues. Depending on how XQs is configured, and the file types that are selected, the actual tasks are performed.
So you have 2 sets of files FOR EXAMPLE:
download.par2
download.vol....par2
download.part001.rar
...
download.part090.rar
AND
MyAvi.rar
MyAvi.r00
...
MyAvi.r32
So for example: shft-d&d of two files ,download.par2 and MyAvi.rar, will cause a RepairThenExtract for download.par2 (deleting all of the par2 and rars when done), and simply Extract for MyAvi.rar (deleting all the rar and r##s when done). To the destination you dragged and dropped them to.
Now if you had a third file that you drag and dropped at the same time, say download.nfo, according to my settings, XQs would only MOVE the three files (in the queue of course). Nothing else would occur as far as repairing and extraction. (Just the way that I have my settings set up, your's could be completely different.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So back in the swing of things. Finishing up the xml config reading code and hooking it into the main task queue manager so that it can create the various tasks and queues on command.
Stuff that's working/unit tested:
* Reading config from xml file
* Individual task execution (so extract already works, at least in a unit testing environment)
To Do:
* Hook up the gui listQ to taskQ actions (like pause, delete, remove, up and down) and customize the display based on task type (BIG)
* Do the task threading execution and locking (SMALL)
Stuff that may wait for alpha/beta 2 so I can check in some code finally:
* Automated xml config modification using a tree control(so do it by hand for now) (MEDIUM)
* ACE,ZIP support (SMALL)
* Some more esoteric options (MEDIUM)
* Progress bars (MEDIUM depending on how I do it)
Excellent!
I'll hold off on my wish list of features until something tangible comes around.
Go ahead and let it out if you want, as it may make a difference in my design/class interface decisions.
Not much time to do it now and it's hard to describe it when it has a lot to do with the GUI.
Basically, I was hoping the finished product would look like an expandable tree where actions are dependant on the success of failure of actions higher in the tree/hierarchy.
This will look sort of messed up on this board but this is a crude ascii representation:
A - Task 1 < top of the tree -- no dependancies>
|
+-- B - Task 2 <dependant on task 1's scuccess>
+-- C - Task 3 <dependant on task 1's scuccess>
+ -- Task 4 <dependant on both task 1's scuccess and task 3's success>
Being able to move things in and out of the task list in real-time would be important.
Another thing would be a right click to a folder to activate a sort of catch-all function which would automatically load a user-definable series of events into the queue.
For instance, an options menu would allow me to decide if I would like to delete par2 files after a successful fix, delete rar files after a successful extraction to the default extraction path, keep par2 history in memory or always do a clean check, look for the first X amount of par2 files in the folder or all of them, ect...
Then when I right click on a folder it would queue up something like this:
- CHECK all par2 files in the directory
- DELETE all par2 files that had a 'Repair not needed' message
- UNRAR all RAR files to the default dir
- DELETE all RAR files after successful extration
Then the same would happen to all par2/rar files in the folder.
Well, that's still not all of it but I'll post more later.
Ugh... the ascii representation didn't really work out.
The bottom + is supposed to be under the C.
You are describing a tree but this is the same thing as my queue of queues:
MainQueue
+RepairExtract
++Repair
+++Delete
++Extract
+++Delete
There is an extract task, and a repair task.
There is a repair/extract queue.
All tasks have a 'delete sources' options, which for Repair would be all (.vol*.par2, but not the original par2 (could make it optionally delete this one too)), and for Extract would be whatever files we discovered belong to the volume set (ace, c01, ...; rar, r01, r02...) during extraction.
So I hadn't thought about doing a folder level 'do something to all par2's in this directory'. It shouldn't be too hard to implement at least some of the functionality you are talking about. Simply when the right context target is a folder it can list Move, Copy, (Zip at some point), and then repair all par2's and/or extract all archives. It would just need to find all of the archives and then extract them to the chosen destination.
I'll have to figure out how I'll represent that in the config.xml but shouldn't be too hard. As it is already, if a single task repair or extract task contains a list of files, it will dedupe the files so that only one per par2 and rar volume set remain, and then creates a sub task for each one.
Keeping track of results after they are out of the queue (like in your 'DELETE all par2 files that had a 'Repair not needed' message' idea) is probably out of the scope of things at this point, as it would require a lot of thought.
That should be 'only one par2 or rar file per volume set' so:
a.rar, a.r01, a.r02, b.part01.rar, b.part02.rar, b.part03.rar
get whittled down to:
a.rar, b.part01.rar
>Keeping track of results after they are out of the
>queue (like in your 'DELETE all par2 files that had a
Well, y'see, that would be the crux of the plan. For something like this to work, you would HAVE to know of a way of checking whether a task succeeded or failed for child processes to initiate.
You can't UNRAR a bunch of files unless all files are deemed OK.
Likewise, it would be prudent to stop the queue if an extraction process to the default drive becomes full. You would have to figure a way of looking for that error msg from Winrar.
I think I'm just misreading this. It's been a long ass day for me. <insert appropriate emoticon here>
>'Repair not needed' message' idea) is probably out of
>the scope of things at this point, as it would require a
>lot of thought.
Currently in QuickPar v.9, an option exists for the following:
- Delete Damaged Files after Repair
- Delete PAR2 files after Repair
- Send files to Recycle Bin
I just thought it would be cool if shellqueue had something similar
>So I hadn't thought about doing a folder level 'do >something to all par2's in this directory'
I'm basically describing some sort of shell integration the same way WINRAR allows users to do:
- Add to archive
- Add to '<CurrentFolderName>'.rar
- Compress and email
Similarly, it would be freaking sweet if this proggy would have similar characteristics where a right-click would show one or a few options (in a cascaded context menu).
If it's just one option, then something like:
- ShellQueue: Queue-It
I'm just throwing these out there. They don't have to stick. They're just suggestions that I think would make it easier to use.
XQs does not use WinRAR.exe, it uses the Unrar.dll directly. As it will UnAce.dll and zlib(zip).
XQs has an (umimplemented at this point) option UseRecycleBin for deletion action types.
XQs will not be able to do anything besides determine success or failure for repair until a par3.dll is released, as there is no way to get this information from par2cmdline currently, unless I hack my own par2.exe and release it as well. Ideally, in the fututre, before repairing XQs will check to see which files are damaged and/or missing. If it's only .nfo and .sfv, then XQs will not repair. Delete Par2s after a successful repair will be supported.
XQs was originally planned as ONLY a Windows Shell Extension (Right Click Context Menu sub menu) in explorer, so yes this will be supported. The first alpha won't focus on that though, but on the Directory Opus overloading of drag and drop. So shift drag and drop will launch exqueues from the Directory Opus version of Explorer, causing files to be moved, copied, repaired, extracted, repaired then extracted, etc. depending on how you have it configured.
So as it is now, the expected 'cascaded context menu support' is as follows: A Base ExQueues Item at the root level (with copy/paste/send to, etc). Then, depending on the file type(s) that are selected (and your settings), options such as move, copy, repair, extract, repair then extract, join, etc. will be listed. Then under each of these (say extract), a list of default destinations will be displayed (c:\My Document, <Here>, <Choose Destination from Dialog>, ./<archive name>, etc.) all chosen by you in the configuration settings.
Okay so 'Keeping track of results after they are out of the queue' meant to me:
You tell XQs to do something(right click/ d&d). It finishes. You tell it to do something else(right click/d&d): XQs will have no knowledge of the result of the first action, besides having logged that information for user validation.
However, the first 'telling XQs to do something' could have been "repair, then if successl delete par2s, then if success extract, then if success delete rars".
Here's an update:
I'm getting pretty psyched. Everything seems to be coming together pretty rapidly. I currently have the DDE support functional.
So a shift-drag and drop in Directory Opus will launch ExQueues if necessary, then pass the destination and the files to ExQueues. Depending on how XQs is configured, and the file types that are selected, the actual tasks are performed.
So you have 2 sets of files FOR EXAMPLE:
download.par2
download.vol....par2
download.part001.rar
...
download.part090.rar
AND
MyAvi.rar
MyAvi.r00
...
MyAvi.r32
So for example: shft-d&d of two files ,download.par2 and MyAvi.rar, will cause a RepairThenExtract for download.par2 (deleting all of the par2 and rars when done), and simply Extract for MyAvi.rar (deleting all the rar and r##s when done). To the destination you dragged and dropped them to.
Now if you had a third file that you drag and dropped at the same time, say download.nfo, according to my settings, XQs would only MOVE the three files (in the queue of course). Nothing else would occur as far as repairing and extraction. (Just the way that I have my settings set up, your's could be completely different.)
Oh, and I forgot to say, IT ACTUALLY WORKS! ;-)