Bring the Catalog to the next level...

[jacky]

Well, this little UDC thing really looks nice, I'll tell you that. I have already mentioned some wishes about constructing our very own menus to make our own groups of UDC. And I still believe this would be really great!

And here's another thing - that you might already have on your list? - I think could also be done to make XY even better, and bringing the Catalog to the next level : brought the power of UDC to it, in a way.

Instead of Destination, why not add a Command list that would include all UDC's categories (Go To, Open, Rename, etc), and rename Destination to Argument.

Then, the "Open on click" checkbox has to go, and instead those items must be assigned to the "Open" command instead of "Go To".

That way, all the "tricks" on Catalog would still work, Ctrl+Shift+Alt Click to scroll there, or drop/Ctrl+Shift Click to open with, but not only could one start an open with operation on one single, simple click, but one could also start move/backup/rename/etc operation using one click as well !


Being more of a mouse guy I'd like that, a lot, as it'd be better/easier/quicker than using the menu interface. Of course, the best would be to also have another possibility, the custom TB buttons

[admin]

When I was talking about scripting, I meant exactly* what you are suggesting here! RAW POWER! This will be added in 6.60 or 6.70. Plus, of course, batch scripting, which will be simply a sequence of UDCs processed in one go.

While we are exchanging visions: I'm also thinking of exchanging UDCs! For example, a user who is good in RegExp could design a dozen of useful Regexp Rename UDCs (with meaningful captions!); then he could export those to a file and share it with other users who would import this file to their UDC.dat. "Load a bunch of cool commands!"

* UPDATE Well not exactly... I read your post again. What I mean/intend by scripting is/was a bit different. Your idea is quite nice... there's time for meditation. First I'll finish what's there and publish v6.50!

[graham]

It seems to me that the move to expand XYplorer with UDC and KS is just the start. Now we have the catalog coming into play, what next? Btw, I am already using the backup in catalog frequently and for the type of work I do it is fantastic to take a backup in less than a second of a load of files and not having to assemble it every time.

It appears that all the pieces are now in place and as Jacky has said ready for the next big enhancement - the glue! I think there is some need to 'enhance' the user interface if only to bring it all together in one preferred place. At the moment, as it appears to me, the features are spread around a bit (menu/edit, udc, catalog, ks, right click etc) and whilst many will probably love the variety of options I personally think the measure of elegant design is reducing all these to a minimum without losing flexibility needed by keyboarders or mousers. Version 10 possibly but I am absolutely astonished at how robust and the betas are given the progress made over the last weeks.

Picking up on the export of Regexp rename UDC's concept. I really like this and wonder if this could be similar to the TOTD where users can view and extract ready made code to either use or modify - maybe Expert Tips?

[admin]

Btw, I am already using the backup in catalog frequently and for the type of work I do it is fantastic to take a backup in less than a second of a load of files and not having to assemble it every time.

Thanks for the feedback! I'm not sure whether it has been done like this before (recreating all parts of the source path in the target folder). So it works for you, great!

[admin]

Btw, I am already using the backup in catalog frequently and for the type of work I do it is fantastic to take a backup in less than a second of a load of files and not having to assemble it every time.

So, if this is so fantastic, how urgent is "integrated backup management"? Actually I lowered its priority a bit, and now will move straight on to Undo!

[graham]

Well for me the new backup achieves all that I need. The fact that it backs up to a single location is no concern especially as you preserve the path should a file need restoring. So for me I am more than happy for the next step in this be delayed.

I do think that undo is a far more important feature and look forward to that. Could an individual file restore be considered in the undo? Having a backup feature is great but it is there only because one may have to restore either a file, directory or complete backup so maybe this could be included as 'undo'
Thanks anyway for the backup.

[admin]

Could an individual file restore be considered in the undo? Having a backup feature is great but it is there only because one may have to restore either a file, directory or complete backup so maybe this could be included as 'undo'

The main idea of Undo is to quickly undo a mistake (an Whoops!-action), or a row of mistakes (rewind some steps). There's always the recycle bin to do individual retores days after the deletion happened.

BTW, programmatically restoring items from the recycle bin is surprisingly difficult to do. Windows gets very unfriendly here and you are forced to to hack into the bin to do it. It's fun...

[graham]

Yes I can imagine windows is a nightmare.
What I meant by restore was not from the recycle bin but from the backed up locations - sorry I should have made myself clear!
The idea being that having made a backup one would use the catalog to request a restore from backup. Of course this can be easily done by copying from the backup location. Not essential in any way but just a rounded feature for catalog backup.

[admin]

Yes I can imagine windows is a nightmare.
What I meant by restore was not from the recycle bin but from the backed up locations - sorry I should have made myself clear!
The idea being that having made a backup one would use the catalog to request a restore from backup. Of course this can be easily done by copying from the backup location. Not essential in any way but just a rounded feature for catalog backup.

Ah, okay. But the Catalog must know the backup location for this. But it does not.

[graham]

Admin wrote:

Ah, okay. But the Catalog must know the backup location for this. But it does not.

Quite right but how about this variation?

Restore a file from Backup.

Having made a backup and the user needs to restore an individual file or folder then this could be done more elegantly by having a Restore instruction.

To work the user would select, in the backed up location, the file or folder required and then select the restore instruction restore. XY would then check to see if the selected file was a backup by looking at the address for a backup signature and then re-create the proper destination from this.

The Restore command could reside in User/Backup.

Example:

Backup: XYplorer folder (eg C:\Program Files\XYplorer
To: MY Documents\Temp

User select file to restore: XYplorer folder in MY Documents\Temp
Instruction: User/Backup/Restore
XY check: Valid or error msg
XY construct from: MY Documents\Temp\C\Program Files\XYplorer
XY copy to original: C:\Program Files\XYplorer

Not in any way essential but it does help decode a long backed up address to make the restore copy.

[admin]

Admin wrote:

Ah, okay. But the Catalog must know the backup location for this. But it does not.

Quite right but how about this variation?

Restore a file from Backup...

Starting from here, what about this idea: you know the "breadcrumb" toolbar button (sub-button of the "Up" button). What about a "Restore To" button!? Say, you are currently in MY Documents\D\Temp\C\Program Files\XYplorer\ from which you want to restore some files. Now you click the "Restore To" button. A menu pops up where all possible destinations derived from the current destination are offered. In this case there would be two (okay, I skip \\servers here):

C:\Program Files\XYplorer
D:\Temp\C\Program Files\XYplorer

One more click will start the restore.
Most of the times, of course, there would be just one possible destination derivable from the backup path -- in which case the button could skip this step (of popping the menu) and simply start the restore operation!

[graham]

Say, you are currently in MY Documents\D\Temp\C\Program Files\XYplorer\ from which you want to restore some files. Now you click the "Restore To" button. A menu pops up where all possible destinations derived from the current destination are offered.

Yes of course, very nice and I guess easily implemented - like it (wish I had thought of it though - to be honest I rarely use breadcrumb so that's my excuse)

[admin]

Say, you are currently in MY Documents\D\Temp\C\Program Files\XYplorer\ from which you want to restore some files. Now you click the "Restore To" button. A menu pops up where all possible destinations derived from the current destination are offered.

Yes of course, very nice and I guess easily implemented - like it (wish I had thought of it though - to be honest I rarely use breadcrumb so that's my excuse)

Now, to have any chance to derive a server (UNC path), I must add something special to the "server-folder" when backupping from a server. For example a prefixed @??
source: \\server\share\path
target: C:\backups\
result: C:\backups\@server\share\path

This would also solve a problem I had not thought of yet: if a server is called e.g. "\\D" (don't know if that's allowed) then its backup would merge with that from the drive "D:".

[j_c_hallgren]

Just be aware that I use the "@" as first char of some of my filenames...and I also use it within others...I also have some folders with "@" as first char...

However, I don't use a server here...but I did years ago with same naming schemes...

[admin]

Just be aware that I use the "@" as first char of some of my filenames...and I also use it within others...I also have some folders with "@" as first char...

However, I don't use a server here...but I did years ago with same naming schemes...

Yes, I expected something like this... it's a dirty solution... needs some meditation...