What do you think about the new separate directory tree?

[Lefteous]

There has been a poll where users could check which of the new features of TC 7 they actually use. One of the major features of TC 7 has performed quite poorly in this poll. So far only 5 of 40 users are using the new seperate directory tree. I might be interesting to know why many people don't use it. The author has spent a lot of time in implementing this tree and I wonder if this was a good investment. Maybe the author can get an idea from this poll if developing the new separate directory tree was a good idea or not and if future improvements to the separate tree could be a good idea or not.

[icfu]

Well, the known story:
F2 doesn't rename but does cm_EditPath, F5 and F6 still give error messages ""function not supported".

With Ctrl+X and Ctrl+C the tree just acts ridiculous and kind of dangerous:
You are expecting that the current directory is copied or cut to the clipboard (like in Explorer), you even get a slight flickering (which ghisler seems to prefer to send "signals" that something has happened) but oops, nothing happens, the clipboard doesn't change. When pressing Ctrl+V hopefully you will recognize that...

If the tree control would be equipped with an integrated realtime quick filter field, like Alt+F10 but with more options, the tree could become a very useful component which I would use regularly but nevertheless all those downsides have to be eliminated in the future.

Also other nice things are happening in Explorer tree controls meanwhile, like tracking cursor position so horizontal scrolling is done automatically. I don't know if ghisler even thinks about such fancy stuff. Imho he should.

Icfu

[Lefteous]

2icfu

f the tree control would be equipped with an integrated realtime quick filter field, like Alt+F10 but with more options

There is a quick filter field in the change directory tree? How can I use it Do you mean the quick search?

Also other nice things are happening in Explorer tree controls meanwhile, like tracking cursor position so horizontal scrolling is done automatically.

There actually is some kind of automatic scrolling. If the start of directory name is hidden TC scrolls horizontally.

[icfu]

There is a quick filter field in the change directory tree? How can I use it Do you mean the quick search?

Yep, sorry, I am starting to confuse how things are called in different file managers. I mean a realtime quick search, equipped with wildcards, a history, the possibility to choose which treeinfo files should be searched, refresh buttons for all and single treeinfo files, stuff like that, many ideas...

There actually is some kind of automatic scrolling. If the start of directory name is hidden TC scrolls horizontally.

The stuff I mean is this:
http://www.istartedsomething.com/20061102/dynamic-multi-scrolling/

But, the horizontal half-automatic scrolling in TC is not that bad, maybe it would even be sufficient with a decent quick search.

Icfu

[Lefteous]

2icfu

Yep, sorry, I am starting to confuse how things are called in different file managers.

For me a quick filter shows only items which match a search pattern. A quick filter would select items which match a search pattern.

I mean a realtime quick search, equipped with wildcards, a history, the possibility to choose which treeinfo files should be searched, refresh buttons for all and single treeinfo files, stuff like that, many ideas...

Unlike the change directory tree the current separate tree is limited to the visible items. I think this is a real disadvantage. I personally think of a search based on an index file. The treeinfo is not really a good base for a real-time search.

These are the current operations for the quick search operation in the separate tree. You probably know them but there may be others you didn't read the history file completely

Code: Select all

30.08.06  Added: Quick search in separate tree: ENTER opens selected directory, ESC jumps back to previous, INSERT stays on new dir, but only opens if configured to auto-open
30.08.06  Added: Quick search with letters only now also works in separate tree
29.08.06  Added: Quick search with Alt or Ctrl+Alt now also work in separate tree (letters only to be added)

[icfu]

Unlike the change directory tree the current separate tree is limited to the visible items. I think this is a real disadvantage.

Indeed, and Num* for expanding all subnodes hasn't been implemented unfortunately.

I personally think of a search based on an index file. The treeinfo is not really a good base for a real-time search.

I agree. In theory I would operate a TC which directly accesses the MFT like this neat app does:
http://ndff.hotbox.ru/en/index.html

I don't know if it isn't better to first use what's already there (treeinfo files) and replace the function which returns the names later when a decent indexing feature is developed/implemented.

Icfu

[Stance]

The separate directory tree is turned off by default here, because I didn't use it every day.
I have Petermads Menus extended for to show the first directory tree with: cm_ToggleSeparateTree1 in the right panel and cm_ToggleSeparateTree2 will show the 2.directory tree in the left panel.

For me this is the one and only functional treeview in Total Commander.
I never liked to use cm_LeftTree/cm_RightTree and was very unhappy with the CD-Tree.

I voted for:
The current implementation definitely needs improvements but I'm already using the separate directory tree.

[Flint]

I don't use separate directory tree, just because I don't need it. I was using it quite a lot during testing (to check bugs and fixes, to see what history items mean), and nevertheless couldn't see any advantage of using it (not because of some problems/misfeatures, but just because of the whole concept itself; when I have to use Windows Explorer (brr...) I don't use its tree pane as well).

So, I vote for "The current implementation is fine but I don't use the separate directory tree".

[petermad]

I totally agree with Flint.

[JohnFredC]

Wow! This poll is like an invitation to me to post another lengthy rant about the trees!

I wanted tree functionality in TC in a bad way, but sadly I rarely use TC's trees because:

1. I loath the single separate tree and will never use it. Thank goodness I don't have to.

2. TC trees lack standard...

...mouse behavior (the connecting lines aren't enabled for expand/collapse), inline renaming (!!! was that really a design decision???), drag/drop functionality. Many of the things one would use the tree for just aren't implemented.

3. There is no way to show just only one tree, INSIDE a tab, on the right panel. What was the design thinking there?

SpeedCommander's approach works well: two toggles: one for a left tree and one for a right tree. Plus, SC remembers tree visibility for each tab, the tree is INSIDE the tab, is the child of the tab. One selects a folder tab and there is the tree. Select another tab for which you don't need the tree and the tree disappears. TC forces at least 2 clicks AND one gets a second tree one usually don't need and which messes with the column layout on the destination side.

See my comment at the end below about WHY I think this happened (er, didn't happen).

4a. The tree splitters don't respond to panel splitter position. For instance: display both trees, then display quickview. If the quickview splitter is not near 50%, the file panel becomes nearly useless unless one drags the tree splitter. A separate setting for the tree splitter in quickview is essential.

4b. There is no intelligent handling of the file panel columns in tree mode (or any other non-50% splitter mode: this broad failing of the TC interface design is shared by most file managers). IMHO the best solution would be user-assignable fixed ("frozen") columns in the file manager with a horizontally scrollable area to the right (just like Excel's "freeze columns" mode). The setting should be customizable for each column layout. Is this just too hard to implement?

Another idea: If frozen columns are too hard to code, then an alternative would be to assign 2 column layouts per tab: 1 for "normal" (panel splitter at 50%) viewing and one for "quickview" or "narrow" viewing. So when the panel is too narrow, TC would automatically switch to the reduced (ie. narrower) column layout. The two views could be specified in an enhanced tab properties dialog.

AN ISSUE OF PERSPECTIVE

There is an (incorrect) GUI design philosophy (exhibited by most file managers, including TC) that a folder tree somehow is the parent of the file list... that because the tree shows folders and folders contain files, that the file list is subordinate to the tree. Wrong!

Incorrect File System Data Model

Folder -> File -> Properties-> Attributes/Contents

But if one performs a standard data model for day-to-day use of a computer file system, the core entity is the file! The folder that the file occupies is just an attribute or property of the file entity just like any other property such as its name, its size, its contents.

Correct File System Data Model

File -> Properties -> Attributes/Folder/Contents/etc.

The tree is just a filtering device for one property of a file (its folder location property) and as such should be suboordinate to the file panel.

[roentgen]

Same opinion as Flint. I didn't use it in my long gone explorer days, I have no use for it now.

I might add that one separate tree is taking to much space for me to support it more than 5 minutes. Two separate trees are overkill in that matter.

Explorer, with its only one file list, does not have this limitation.

Other than that, the tree requires to much mouse involvement to my liking.

Why did it get implemented in the first place? Did anyone request it?

[MayorA]

Thanks to this poll I played around with the trees again, after having used them rather rarely.
As a keyboard addict I am quite comfortable with the current implementation and will most certainly use the tree view more frequently.

[Clo]

2Lefteous

Hello Christian !

• I voted #4 (the very first vote !).

• Just some thoughts on the fly :

¤ Like Flint and Petermad, I don't need that.

- Moreover, I'm “tree-allergic”, it's the reason for which I use W¦TC for a decade.

¤ The icfu's and JohnFredC's remarks and criticisms seem totally justified…

roentgen wrote

…Why did it get implemented in the first place? Did anyone request it?

• I did not, certainly ! My requests have been else and modester (though not considered a lot…)
- I suppose that this has been added especially to catch Explorer-addicted newbies…
- Well, why not ? But in such a case, a feature must be quite functional
(I mean : similar) and totally optional (I mean : at the installation-time).

 VG
Claude
Clo

[Lefteous]

Talking of design approaches - normally a design process includes identifying targetted user groups. Reading the posts in this thread it's clear that separate directory trees is a feature that isn't used by all user groups. Trying to be all things to all men can lead to make it right for noone.

[Clo]

2Lefteous

Trying to be all things to all men can lead to make it right for no-one.

I agree totally…

«Grasp all, lose all»

 VG
Claude
Clo