We can double-click an entry in the "Folder statistics" window to reach the actual folder/file (in the active pane).
During this analysis, the user may want to browse through the neighboring folders/files. At this juncture, he should be able to come back to the "Folder statistics" window, and jump directly to the folder he is currently browsing through.
This two-way freedom of movement will be particularly useful when the folders/files have a deep hierarchical structure (as in case of a typical web-strcuture).
This would be a significant change, because there is no "find" function available in the "Folder statistics" window, and the only way the user can locate a particular folder is to expand each path and look.
(Of course, the only condition is that the user must not wander away from the top-level folder being displayed in the "Folder statistics" window! )
BTW, I feel that the "print" option in the right-click menu of the "Folder statistics" window is a misnomer: it should be named "copy to text file").
Synchronize "folder statistics" window with panes? - Freedom of Two-way movement!
Moderators: fgagnon, nikos, Site Mods
-
nikos
- Site Admin
- Posts: 16341
- Joined: 2002 Feb 07, 15:57
- Location: UK
in an ideal world this would be possible, but then again this is the real world
no way you could do that with the present folder data dialog. I am thinking of an extra command in the folder data itself that goes "sync with active view" but that would have to wait for when this particular command makes it into x2
> "print" option in the right-click menu of the "Folder statistics" window is a misnomer
how about calling it with its even more exact name "dump the expanded tree contents into a text file with the intent of printing; sir/madam is kindly requested to collaborate a little by clicking on the print button once the editor pops up"
-- where do you draw the line?
no way you could do that with the present folder data dialog. I am thinking of an extra command in the folder data itself that goes "sync with active view" but that would have to wait for when this particular command makes it into x2
> "print" option in the right-click menu of the "Folder statistics" window is a misnomer
how about calling it with its even more exact name "dump the expanded tree contents into a text file with the intent of printing; sir/madam is kindly requested to collaborate a little by clicking on the print button once the editor pops up"
-- where do you draw the line?-
narayan
- Platinum Member
- Posts: 1430
- Joined: 2002 Jun 04, 07:01
Sounds like a great idea (the "sync" command-- not the paragraph in place of a command 
)
Regarding the "print" command, I felt the commands should be named after the action they directly precipitate, not the ultimate use/intent.
Here, the action ends with generation of the text file: it is not step-2 in a three-step printing process (like Mikro$oft WORD providing a print-preview before you take a print).
In fact, my preferred way of using this output is to copy the text file and paste it in Excel. Since it is a tab-separated file, the different levels of the files/folders automatically fall in different columns. Parsing this data further is oh so simple and completely paperless
So, why call this wonderfully flexible command just "print"?
)Regarding the "print" command, I felt the commands should be named after the action they directly precipitate, not the ultimate use/intent.
Here, the action ends with generation of the text file: it is not step-2 in a three-step printing process (like Mikro$oft WORD providing a print-preview before you take a print).
In fact, my preferred way of using this output is to copy the text file and paste it in Excel. Since it is a tab-separated file, the different levels of the files/folders automatically fall in different columns. Parsing this data further is oh so simple and completely paperless
So, why call this wonderfully flexible command just "print"?