TC 7 [req]: Temp Panel/Virtual folders

[szlori]

Perhaps as a first implementation of "virtual" file panels in TC, NO action taken on an entry in a virtual panel should effect the original file (only the virtual one). That would get us the list capability with an understanding that the originals aren't touched. Easier to implement I expect? Safer.

Nope, I don't agree here. For me the "virtual folders" (that's how I would call what I wish for) contain only "pointers" to original files. Their "only" purpose is to group different files fro different locations into one "virtual" place. So of course, I want all operations on the content to be taken on the original files.

Ability to create folders in the virtual panel, add "files" to them, and in all ways have them act like actual folders.

I specifically voted for no subfolders since Christian said it is much harder to implement it that way...

All data columns (name, size, date, etc) applicable to the original file should be selectable to appear in the virtual panel, be filterable, sortable, etc. Including columns from content plugins.

Agree.

Ability for the virtual panel to maintain its own integrity. For instance, if the panel is fed from a Search dialog ("feed to listbox"), then it should self-refresh at user set intervals... upon displaying the folder, every n minutes, return to root, etc... some schema that is workable, configurable, and not vulnerable to misinterpretation. For example, things like file size and date (of the original) should be maintained "live".

Of course, that's what I said myself as well, only that I put it optional as it's clear that this needs extra coding.
And I'm more keen to have a less featurefull version than nothing.

A choice to show missing referents with color or to simply automatically remove the entries for missing files would be good. For instance: in SC an entry in a File "Container" shows red when its referent file is missing.

Simply remove should be enough. Of course, the list should not contain "pointers" to nothing. If you're a programmer you know how bad that is.

What would we call these panels. Temporary panels? Virtual folders? Temp Lists? Containers? Organizers?

For what I wish for "Virtual folder" or "Organizer" would be suitable.

What do we call their contents? Virtual files? Links? Ghosts?

Links...

[Balderstrom]

Nope, I don't agree here. For me the "virtual folders" (that's how I would call what I wish for) contain only "pointers" to original files. Their "only" purpose is to group different files fro different locations into one "virtual" place. So of course, I want all operations on the content to be taken on the original files.

I think a special case would need to be made for "delete" - delete in a Virtual Folder should just remove the link (to the file) from the container. Perhaps ctrl-delete would remove both (the link and the actual file - and send to the recycle bin if enabled), and ctrl-shift-del - delete both (kill, no recycle). But that is possibly confusing... how do other apps with these special containers handle delete et al?

And unlike in 'nix, from my experience with HardLinks in Win2K, deleting a hardlink does not delete the actual file - just the reference to it.

[szlori]

Good point, Balderstrom.

My view is that this folder should behave just like a real one.
So, delete should delete the real file.
Virtual folders should have additional command to "remove from virtual folder".

Also, on the other hand, one should not be able to create files in the virtual folder, only "add" (more like linkto) from a real location.

[icfu]

how do other apps with these special containers handle delete et al?

Pressing delete is handled as removing the link only in xplorer2 and Speed Commander.

So, delete should delete the real file

This is not acceptable at all, this would be completely contraproductive for quickly wiping out the results of a search for example. Pressing delete+modifier key to delete the file would be perfectly ok of course, but not as default handling.

xplorer2 uses ctrl+del to delete physically and shift-del like usual, this works wonderfully.

Icfu

[szlori]

So, delete should delete the real file

This is not acceptable at all, this would be completely contraproductive for quickly wiping out the results of a search for example. Pressing delete+modifier key to delete the file would be perfectly ok of course, but not as default handling.

Well, that's your point of view; I prefer to have "special" command to remove items from the virtual folder, the same way as the virtual folder is constructed by special means.
There could be a command to clear the content of the virtual list, another to remove one item, etc...
For me, other than this (building up the list, that includes removing elements too), the virtual folder should behave as a real one. So when I want to delete the file I could do it just the sme way from the virtual folder as from the real location.

[icfu]

Virtual containers just don't "feel real", in fact they are collection of file and folder links and deleting a link should never touch the real file. This is, for example, why TC does not delete the original folder when deleting a junction when using TC deletion method.

Also the action "remove from list" is naturally done way more often than a physical deletion and the most used action should be bound to the key directly, not to some modifier.

And a last reason: Creation of virtual folders in virtual containers is a very cool sorting feature I don't want to miss. If you press DEL on such a virtual folder there is no physical folder that can be deleted, so you would get a rather inconsistent and confusing behaviour.

I think an INI option to switch between remove/delete would be completely sufficient to make you happy without the need to confront other users with unneeded dangers.

Icfu

[szlori]

Also the action "remove from list" is naturally done way more often than a physical deletion and the most used action should be bound to the key directly, not to some modifier.

I can live with this, I guess, but then virtual folders should be very clearly distinguishable from normal folders, so you know what to press.

And a last reason: Creation of virtual folders in virtual containers is a very cool sorting feature I don't want to miss. If you press DEL on such a virtual folder there is no physical folder that can be deleted, so you would get a rather inconsistent and confusing behaviour.

For this case, I would say that virtual folders should not appear together with real folders. Maybe only as tabs, or in best case together with the FS plugins (in network neighborhood).
So, what happens when you press delete on such an item?

I think an INI option to switch between remove/delete would be completely sufficient to make you happy without the need to confront other users with unneeded dangers.

I'm not unhappy, only that you couldn't fully convince me about those dangers.
Normally when you press delete, you want to delete a file. So you're saying that the user will be so much aware that he is in a virtual folder that he will completely switch his mind thinking delete is only "remove from virtual folder"? What I wouldn't like is Delete behaving inconsistently, but anyway, as I said above: I could live with that.

[Lefteous]

2szlori
2icfu

Well, that's your point of view; I prefer to have "special" command to remove items from the virtual folder, the same way as the virtual folder is constructed by special means.

All deleting actions from a file heap (nice name isn't it? ) should be special commands (three at least).
But that doesn't say anything about default hotkeys.

[icfu]

I can live with this, I guess, but then virtual folders should be very clearly distinguishable from normal folders, so you know what to press.

This is highly welcome on my side and a musthave, yep.

So, what happens when you press delete on such an item?

Pressing DEL on all items on a panel removes from list, no matter if they have a physical counterpart or not, that's what I was referring to above when I was speaking about "consistence".

So you're saying that the user will be so much aware that he is in a virtual folder that he will completely switch his mind thinking delete is only "remove from virtual folder"?

Exactly, this is my experience and I have worked with several container systems already. The important point is of course that the user should easily be able to recognize that he is working in something "virtual".

[...] a file heap (nice name isn't it? )

I think that "scrap heap" sounds way better.

Icfu

[JohnFredC]

I think "Organizer" and "Item" are sufficiently unambiguous and extensible in meaning...

[Ithier]

I think it has not been mentionned but loading an "Organiser" from a text file could be very interesting.
For example you could use an external program to make a search (like locate32 discussed here: http://ghisler.ch/board/viewtopic.php?t=7235&highlight=locate32) and then load it in TC.

[Balderstrom]

I have to agree with Icfu for the most part, something as simple as making the default VirtualFolder blue instead of yellow would be enough of an indication - of course it would need to be able to be modified like the other file type icons in TC are.

[JohnFredC]

something as simple as making the default VirtualFolder blue

I don't understand this remark. What folder? Where?

[Sheepdog]

something as simple as making the default VirtualFolder blue

I don't understand this remark. What folder? Where?

Guess the icons in the TC file window for virtual folders (in contrast to the normal yellow folder icon). Like 'Desktop' to let you know it's virtual not real.

sheepdog

[Balderstrom]

A blue virtual folder, was assuming one could create one within any given directory, much like you can with a junction currently - though a junction needs to actually point to a valid directory. The way This could be handled perhaps is for TC to have a subdirectory in its path

\TotalCmd\VirtualFolders\Test1\
\TotalCmd\VirtualFolders\NewZip\

Many mention wanting to have these Containers to not be volatile and persist between reboots/TC restarts. Obviously some way to store the information would be required. The above seems the easiest to me. Instead of the limiting the implementation to a "Virtual Tab"