Saving the marking of files and/or folder

[pdavit]

Dear friends,

Here is a wish for a feature that I think most users will find welcome. It’s rather an expansion of an already implemented feature and I would appreciate your feedback!

I usually make a selection of files and/or folder for coping or other file managing tasks and sometimes when I need to enter an archive or folder to verify their contents for selection I loose my marking. So, when I go back the tree of folders (or out of an archive) to continue with my marking my selections are not there and I have to go through the selection process from the beginning. I think it would be a nice idea to have a function for keeping the current (last) selection if a users wishes to enter an archive or a folder and then go back to continue his/her selection.

I think I’m not speaking only for myself but the aforementioned working behaviour is followed by most users. I presume there is no need for hardcore programming in order to implement this feature and a function to save (in memory) a selection and be able to recall it should do the trick!

Remark: The “Restore selection” function we currently have for TC does not provide the functionally I described above unless I’m missing something here! (Quoted from TCs help file: “Restores the selection which was active before the last file operation. Press the / key (divide) on the numerical block of your keyboard”)

Based on the above description and some tests I performed, a marking restoration can only be achieved after the last file operation. So far so good, and TC behaves smoothly in the aforementioned case but changing a directory or entering an archive is not treated by TC as a file operation action (correctly I presume) thus the loss of a selection when someone goes back the folder tree or out of an archive hence the inability to recall a selection by using the restore feature as it is now!

Is there a way to extend the “Restore selection” functionality Christian so that a marking can be stored even when a user changes folders and/or enters archives and not only after file operations? If there is a possibility of performance drawbacks then an option to deactivate the feature in the configurations or the ini file can be a workaround!

Any help or suggestions would be mostly welcome guys.


Kind regards,

Panos

[Valentino]

Panos, if this is implemented you may encounter the opposite situation - when you may want to restore selection of files that you performed some action on, but due to going back and forth to other dir, you lost those selection... It's about automatic selection saving.
Some new command for manual saving will help, but it's probably like "using a steam-hammer to crack nuts".
Maybe you just go to where you want in opposite (target) panel to take the name you want, and thus preventing selection in source panel? And then you may go back to original place in target pane with Alt+Left Arrow.

[scannert]

I would like this feature too, especially while doing ftp transfers. It would be better to save the selection then to login to the ftp server twice and read the contents of a directory.

[apz]

this is my, somewhat convoluted, workaround:

1) mark what you want (files only)
2) alt-f5
3) choose dirlist plugin
4) generate


you got your marking of files saved...

now, nice, but not that much usable, we cannot get the pane to remark the files as saved in the .lst file, or can we:

1) on one pane open the .lst file
2) on other pane open where we want to remark the files
3) press shift-f2 for quick file comparison
4) switch on to the pane that got marked in reverse and use the keypad *

woo, we are done...


as mentioned: this wont work with directories, and might actually be screwing them up. Not sure if its a .INI issue, or how the shift-f2 works.

neverless, this is as close to saving selections/marked files as I have been
able to come up with.

[Ergo]

2apz

this is my, somewhat convoluted, workaround:

It seems to me that your workaround is like going to London from Paris through Africa.
As a real workaround Temp Panel can be used, but this is also not exactly what pdavit needs.

[pdavit]

Thanks for the feedback guys. It seams that the suggested feature is welcome and based on the fact that Christian is open-minded he will think twice in implementing it.

As Valentino correctly suggested here the best path to follow is a manual saving. The algorithm is already implemented by Christian which is accessed (hidden from the end user) only when a file operation takes place.

Now the only thing that has to be done is to assign a shortcut to a new internal command that will point to that algorithm that does the saving so whenever we use the Restore Selection function we’ll have the desired result!

Not to mention that in this way the Restore Selection function will stay intact from any modifications. So, no extra workload for Christian. The current functionality of TC will stay as it is but if my suggestion is finally implemented we’ll get an additional capability of being able to restore a user-definable point for restoration!

It’s probably a 20 minutes coding effort!

[Valentino]

I just noticed (and you might notice too) that we started estimating the volume of necessary Christian's work to implement particular features It happened several times already. Maybe this is "bad tone"? I already did it myself a couple of times...

[pdavit]

>Valentino
> I just noticed (and you might notice too) that we started estimating the volume of necessary Christian's work to implement particular features It happened several times already. Maybe this is "bad tone"? I already did it myself a couple of times...


On the contrary!!! It only shows how much we care about him and the quality of his efforts. We never demand a feature we just ask for it!

[Hacker]

And I miss Black Dog to "veto" all your unnecessary suggestions.



Roman

[pdavit]

>Hacker
>And I miss Black Dog to "veto" all your unnecessary suggestions.

Me too!

Well, I miss the “vetoing” part but do you think this as an unnecessary suggestion?

To be honest with you I kinda find the current behaviour unnecessary under certain circumstances. For example, you can (theoretically) restore a selection after coping or moving some files but practically it’s useless if you have moved them coz the selection is not available in the source location!

Isn’t more powerful (in addition to the automatic restoration points following file operations) to have the ability to user-define a restoration point or at least have TC keep trucking user movements for folders and archives?

I’m not asking here for something fancy or extreme but I constantly find this missing feature as…. well, missing! Not to mention that some users have posted here alternative methods for doing what I have asked (some not very practical) which only proves that users do follow side-methods in order to achieve tracking of selection restorations!

BTW, I like your new avatar!

[Hacker]

do you think this as an unnecessary suggestion?

I don't know. If I had to do it manually I would definitely forget to do it before I do something that clears the selection by accident. And automatic selection keeping would make me hit Gray-, Enter all the time. It also might be dangerous if I select a file, change the dir, change back and decide to delete some files, then the file I had selected before would be deleted, too.

I don't know, would have to see how it's implemented (if ever).


I like your new avatar!

Thanks. I actually had it for a long time, but eforum.de didn't accept PNGs...

Roman

[pdavit]

>Hacker
>If I had to do it manually I would definitely forget to do it before I do something that clears the selection by accident.

My suggestion of folder and archive tracking/movement can solve this problem to some extent. Remark: I didn’t suggest to replace the automatic selection tracking with a manual one. I suggested to expand the tracking method and if possible include in addition a manual one.


>And automatic selection keeping would make me hit Gray-, Enter all the time.

It is currently automatic. Although TC saves a selection only after file operations. The Gray – you refer to could have been users’ behaviour if there was an automatic restoration and not an automatic selection keeping. I didn’t suggest the former! I always wanted the restoration to be manual as it is now. The saving is that concerns me!

A problem I can see with the concurrent existence of automatic and user-definable selection saving is one overwriting the other one. This relies on the users’ judgment though as well as his/her steps that can cause the automatic method to trigger some movement and overwrite the user-definable restoration point.


>It also might be dangerous if I select a file, change the dir, change back and decide to delete some files, then the file I had selected before would be deleted, too.

Correct me if I’m wrong but this problem is already present in some cases! Any way, I don’t think it can be dangerous as we are dealing just with selection saving and restoration and no file operations are applied on the files/folder being selected so no immediate treat!

Edited: To put it in another perspective: How often do you (the users) use the / key (divide) on the numerical block and the Restore selection feature in general?

If I’m allowed to speculate not very often or even not at all!! But that is not because you find the idea useless but because the feature as it is implemented currently is not very reliable as you can easily loose a selection as well as being able to restore (theoretically) selections of files/folders that are not present (after moving them so practically the / key does nothing when pressed).

What I suggest will provide more interactivity and more feedback from the feature as the increased number of selection tracking will increase the number of successful restorations if you know what I mean.

[Hacker]

The Gray – you refer to could have been users’ behaviour if there was an automatic restoration and not an automatic selection keeping. I didn’t suggest the former! I always wanted the restoration to be manual as it is now. The saving is that concerns me!

Yes, sorry, overlooked it. Might be nice.


Edited: To put it in another perspective: How often do you (the users) use the / key (divide) on the numerical block and the Restore selection feature in general?

Well, I tried to use it a couple of times, but as it wasn't working with AlwaysCopyInBackground I didn't have much fun with it.

Roman

[pdavit]

I was playing around lately with a file manager called Servant Salamander (a well known file manager I guess) and I’ve noticed that SS follows my suggested approach on saving and restoring selection lists of files.

With v2.5 beta 1 of SS this functionality extends to an even further flexibility where when trying to restore a selection you get the following four useful options:

- Copy over current selection
- Add to current selection
- Subtract from current selection
- Intersect with current selection

I’m the type of users that uses storing and restoring selections very often but I find TC’s approach very limited. The biggest disadvantage with TC is that you have to perform a file operation in order to store a selection list while SS follows the user-definable storing approach, which IMHO is better.

I would love to see a similar functionality for the up-coming v6.0 of TC.

[ghisler(Author)]

Do you mean storing selections internally, or to a file?