What do you think about the new separate directory tree?

[JohnFredC]

Trying to be all things to all men can lead to make it right for noone.

I too think that is what happened. But also IMHO the design team members don't themselves use trees very much (if at all) and so aren't as cognizant of why people like me use them, nor (more importantly for the design and implementation of folder trees in TC) how people like me use them.

There is also an undercurrent here of the nonsensical attitude that if something is done a certain way in Windows Explorer, it must by definition be wrong!

Trees can be used for navigation, but they are also drop targets, organizers, structure visualizers, asset discovery tools, etc. etc.

There now exist decades of prior art in implemented tree controls used for the manipulation of hierarchical data in software. No need to re-invent the wheel, find some appropriate prior art and use it!!!

[sqa_wizard]

Trees can be used for navigation, but they are also drop targets, organizers, structure visualizers, asset discovery tools, etc. etc.

Fully agree !

I hate the tree of Win Explorer and love the TC panes without tree.
With TC 7 we have got a tree even here and I started to use it for quick navigation and drag&drop of files to far away folders.
I tried single and dual tree, but dual tree is bad designed : It breaks the dual pane view and inhibits to see both sides line by line.

Having a tree on the very left and very right side would keep the dual pane view and just frame it.
This would not break the view but add a "tree-frame".

Nevertheless we may have to take in account, that this is the very first try to implement a tree at TC !
So there is still room for improvement at upcoming versions.

[ghisler(Author)]

Unfortunately I have more or less given up the separate tree in TC, and I will probably remove it in TC 7.5. Why? Although it has been requested a few times (by Explorer users?), it really makes no sense in a program which is mostly used with the keyboard. There is no speed gain to change directories via a tree, when there are much faster ways like directory hotlist, history, or simple switching through the dirs in the file panel.

I fear that a "breadcrumb" bar as in the Windows Vista Explorer will see the same fate: It's something for mouse users, a keyboard user is much faster pressing a few times backspace (go up) and then jump with the quick search to the desired folder and press ENTER.

[Lefteous]

I'm also not sure if a directory tree is something that I will use all the time. The reason has - I guess - absolutely nothing to do with the directory tree itself. It's because I'm used to navigate using the filelists for years. Looking at the facts makes the tree quite interesting for navigation. There is no other way to browse through the filessystem without changing many directories before reaching the target directory and seeing the hierarchy as a whole. Using the directory hotlist or tabs covers only previously configured "hot" directories. That's great for the most commonly visited directories but not for other directories.

What I don't understand is the statement that the tree is mainly used by mouse users. I see absolutely no argument which could prove this.

The downside of a tree is of course that the focus is moved from the filelist to another control. This is something which doesn't apply to the breadcrumbs as these are only pop up menus. I guess it's feasible to make a very good breadbrumb impementation also for keyboards users.

There are obviously many small things which makes working with the tree uncomfortable in the current implementation - also for mouse users. I want to highlight the auto jumping cursor when opening a large directory and the missing scrolling ability when trying to scroll when drag&drop (works fine in the file lists).

[icfu]

Unfortunately I have more or less given up the separate tree in TC, and I will probably remove it in TC 7.5.

To hear this from a developer who refuses to remove cm_EditPersmissionInfo from the internal command set because it would break backwards compatibility, is rather funny.

If you are "really" – I severely doubt – as destructive regarding the separate trees as JohnFredC is being productive at the same time, you should better remove the trees NOW, otherwise some users will get a little pissed very soon, for example those who buy TC 7 because it has trees...

Why? Although it has been requested a few times (by Explorer users?), it really makes no sense in a program which is mostly used with the keyboard.

Missing mouse navigation is a problem in TC. I always wondered why you have always prefered to announce it as a feature.

There is no speed gain to change directories via a tree, when there are much faster ways like directory hotlist, history, or simple switching through the dirs in the file panel.

Directory hotlist and switching dirs in the file panel are static operations. And regarding the history: Is there any "history" of directories you haven't visited till now? Yep, there is: It's called a directory tree.

I fear that a "breadcrumb" bar as in the Windows Vista Explorer will see the same fate: It's something for mouse users,

Even if this was true: What would be wrong with that? Shouldn't it be your goal to make TC the best file manager experience for mouse users, keyboard users and those who like to use both? How do I use the buttonbar without a mouse? There are MANY places in TC that are lacking support for either keyboard or mouse and could need a progressive developer.

a keyboard user is much faster pressing a few times backspace (go up) and then jump with the quick search to the desired folder and press ENTER.

When I want to go from C:\dir1\dir2\dir3\dir4\dir5 to c:\dir1\dir2\bla\blubb\ it's much faster to use breadcrumbs as I only need one click on dir2 and a little mouse movement to have "bla" and the destination "blubb" pop-up. One click on blubb and I am there.

The breadcrumbs feature is most useful in cases where the target directory is not located near the present location and even more when its name isn't known.

Icfu

[Stance]

...you should better remove the trees NOW, otherwise some users will get a little pissed very soon, for example those who buy TC 7 because it has trees...

I agree, -better not to put it into the release of v7 than to remove it in TC 7.5.
It may become a part of the suggested 5th plugin / extension or optional at the installation-time, like Clo said.

I have to say, that (in example) cm_LeftTree together with the new setting in wincmd.ini:
[Configuration]
SingleClickStart=6

And Configuration - Display: (Uncheck)
[ ] Tree: Press ENTER to open dir in other window

...is as simply as never before for mousers and explorer-switchers.

But:
The new separate directory tree brought in fact a third panel into Total Commander, but was never intend to be. When this feature disappears in v7.5, how will it be compensated ? Will there be a better functioning treeview ? (Drag&drop, rename, copy, paste and delete). If no 3rd panel, will there be files in the tree view ?

Shall we fall back to the Alt+F10 cave painting as a replacement ?
Not only new customers will be very disappointed.

[wanderer]

I have single sep tree turned on since b1 but i rarely use it. I never really thought of it but this poll made me wonder why.

Well, it seems that there are two reasons.

1. As it has been analyzed more extensively by other users in this post, separate tree lacks many features. That gives an uncomfortable feeling of an immature late addition to TC not something that is really an integrated part of it. This is logical and acceptable. TC has been improving as a file manager for 10+ years with emphasis in the 2-panel part, not the tree. Sep tree is something new and it has to be treated like that.

I agree with Lefteous, it's not something i would use all the time but it feels nice to know it's there. I never used the normal tree because i always needed to have 2 panels but sep tree is something i have turned on for several months now and even though i rarely use it, i still have it turned on for those few times i'll need it.

2. As Christian said in his post above, "it really makes no sense in a program which is mostly used with the keyboard". Many of us (mostly old-timers) are forgetting that Norton Commander and DOS are long dead. Maybe some of us are used to work only with the keyboard but many of the newer users are used to work mostly with the mouse. Well, sometimes the mouse may be more convenient for old-timers too . Many of the new users probably like TC because of all its built-in conveniences and not necessarily because it can be easily used through the keyboard. I agree that tree is easier handled via the mouse but that's not a reason to kill it.

Having all that in mind, i would vote to leave the sep tree in TC as is. It may not be mature yet but IMHO it is a feature more useful than the normal tree. I think we should be discussing how it can be improved in future versions, not shoot it for being immature.

[StickyNomad]

OK, some points have already been mentioned, but now that I've typed this monster, I will publish it

IMO just because a program can be operated fast and conveniently with merely the keyboard should definitely _not_ be a reason to neglect a possible feature completely, just because mainly mouse users could make use of it.
Both, keyboard and mouse are standard input devices nowadays and more or less used by practically every PC user. The goal for a premium-class file manager like TC should be to acheive an optimized interface for both, keyboard and mouse users.

If I intend so do some file managment, I want to do it fast, fluid and convenient and I will use the appropriate input device depending on the current context and personal preference. E.g. if I'm currently scratching my head with my left hand, I will click on the Toolbar button for quickview to invoke it, otherwise I always would press CTRL+Q. It may be fast to operate an application with keyboard, but in many cases it can be even faster using mouse AND keyboard.


So I would say if you see a slight chance, Christian, that you can implement some of the strongly requested improvements into the tree (Quickfilter, DnD and rename Improvements, one tree at the right side...) in TC 7.5 or later, definitely keep the current trees for now as a start. Even if the current implementation has much room for improvements, the sepTrees are already useful for at least some people among the limited amount of beta users. Projected to the vastly greater amount of people that will use the final, there might be hundreds of people that really can and will make use of the trees.
In addition the sepTrees are optional, so if anyone doesn't use them, he will soon forget that they even exist.

_If_ you really completely have abandoned the sepTrees (I hope you did not), I agree with the others that you should remove them now. Introducing the Trees in v7 when you already know that you will definitely remove them in the next release wouldn't be a wise move IMO. It would certainly annoy many users that like to use the separate trees once they are available, and that would for sure result in numerous complaints when v7.5 would be released without the trees. In addition, it will appear as (and actually be) quite a gap in the otherwise extremely consistent development of TC. IIRC this would be the very first major feature that would be completely removed after its introduction.

So my vote would have been: I quite rarely use the current sepTrees (because I got used to the file-list-way over all those years since ol' NC), but would certainly use an improved tree implementation (with e.g. a quick filter) way more often.


And not least, my 2 cents about breadcrumbs:

I strongly agree with Lefteous that it is possible for sure to make a breadcrumb navigation usable with keyboard too: Imagine you could press some shortcut and the breadcrumb-menu for the current directory would pop up at the path edit field. You then could fly through the directory levels by just using cursor L/R, and with UP/DWN you could navigate through the directories inside a level. This definitely would be convenient, unobtrousive and fast!

I think a well concepted breadcrumb navigation could be a real killer feature and would be a noticeable time-saver for mouse _and_ keybord users. There already exist many different breadcrumb-implementaions that could serve as a source of inspiration to implement the best and leanest breadcrumb bar in the known universe. I really think it is possible to implement a powerful breadcrumb bar that also doesn't occupy too much room. And after all, it could be kept optional.

[wanderer]

E.g. if I'm currently scratching my head with my left hand, I will click on the Toolbar button for quickview to invoke it, otherwise I always would press CTRL+Q. It may be fast to operate an application with keyboard, but in many cases it can be even faster using mouse AND keyboard.

Well said. Sometimes the input method you may use depends on whether you're scratching your head or not. Couldn't agree more.

So I would say if you see a slight chance, Christian, that you can implement some of the strongly requested improvements into the tree (Quickfilter, DnD and rename Improvements, one tree at the right side...) in TC 7.5 or later, definitely keep the current trees for now as a start.

<SNIP>

_If_ you really completely have abandoned the sepTrees (I hope you did not), I agree with the others that you should remove them now. Introducing the Trees in v7 when you already know that you will definitely remove them in the next release wouldn't be a wise move IMO.

Right. This part was also well said. I forgot to mention i agree with that too.

[VadiMGP]

2ghisler(Author)
Mostly I use keyboad but I use mouse too when it gives me some benefit. But regarding trees I have to agree with Lefteous

The reason has - I guess - absolutely nothing to do with the directory tree itself.

I don't understand why you need to remove trees - after all there some users want to use them. But I agree with icfu too - If you are really want to "chop the forest", don't wait TC 7.5. Do it now.

I fear that a "breadcrumb" bar as in the Windows Vista Explorer will see the same fate:

So don't do it yourself! I can repeat my old suggestion - give us the new API! Give us ability to write this "breadcrumb" as plugin. Give us ability to write new toolbar plugins, CPU meter, BTM indicator, etc, etc, etc. Look on Firefox - you can extend it almost unlimited!
In short words: "Give me the new API, and I shall move the earth." © Archimedes

And you can free your time to concentrate on core functionality.

[petermad]

I agree with StickyNomad in all that he writes about the sep. trees.

Regarding Breadcrumbs: Let's see for a while how good they really are in other programs - don't spend a lot of time implementing Breadcrumbs for TC 7.5 - And maybe find out whether Breadcrumbs really is a wish among a resonable amount of users, before spending time making them. I for now am satisfied with the "quick directory changes" feature in the "Current directory header".

I agree with wanderer: Sep trees it's not something I use all the time but it feels nice to have them there. I never used the normal tree either, because I always needed to have 2 file panels, but sep tree (one) is something I use once in a while.

[wanderer]

I don't understand why you need to remove trees

I'm guessing here but a possible reason could be this: if users are not using such a feature that complicates things programming-wise, why not remove it from the code and keep it smaller, cleaner and more effective. It's a valid reason. The actual question here is this: do users really find this feature useless so it can be removed?

[StickyNomad]

2petermad

Regarding Breadcrumbs: Let's see for a while how good they really are in other programs - don't spend a lot of time implementing Breadcrumbs for TC 7.5 - And maybe find out whether Breadcrumbs really is a wish among a resonable amount of users, before spending time making them.

I totally agree. Although I can imagine a decent breadcrumb implementation to be _extremely_ convenient and valuable, I don't want promote this feature to be stuffed into the next TC release at all cost.
Perhaps it would be a good idea to discuss possible breadcrumb concepts here or in the beta forum, to see if implementation is feasible and requested _before_ Christian has to spend valuable coding time.

And If possible via a new kind of plugin like VadiMGP suggested, this also would be OK for me.

[VadiMGP]

why not remove it from the code and keep it smaller, cleaner and more effective.

Of course, it is possible reason. But don't forget - removing it is also work. And it is possibility to add new bugs. So, as always, question "efforts vs. profit". In this particular case the answer isn't obvious therefore I just want to understand what profit Christian see from removing of trees.

[CJ Flash]

I've voted for the second variant, just because I don't need trees. So I agree with Flint`s opinion.

But also I strongly agree with VadiMGP`s suggestion, it will make TC even more flexible and that is good, I think.