Tree implementation incomplete

[JohnFredC]

Thank you so much for the trees! I really want to like them, since I practically begged on my knees for them many times in this forum. And here they are in B1!!!! Cool!

Unfortunately, in their current implementation, they are barely usable for me personally:

1. Need new commands: cm_ToggleLeftTree and cm_ToggleRightTree. I looked through the new include file and couldn't find these commands. These are an absolute must. Without them I probably won't use the trees at all.

2. Need option to "hide folders in file list when associated tree is visible"

3. Need option to automatically save/restore individual tree visibility for each tab. Some tabs don't need trees, some do. It's that simple. Its really important too: At the end of the day, having to keep toggling trees on and off manually is very inefficient.

4. Need separate font/line spacing options for trees. Currently the trees look too much like the file lists... so much so that the two blend together and confuse the eye. Same standards for readability that apply to publication design should apply to TC.

5. Need separate fore/background colors for trees. Same reasons as #4. Currently the tree gets Color 1. Absolutely do NOT need alternate line shading for trees though. The trees are already look too much like the file list.

Perhaps these items are coming in later betas, but since #1 will require new internal commands, I thought perhaps they weren't high on the implementation list.

I need them. Please?

[ghisler(Author)]

1. Sorry, it's not possible - TC would become asymmetric, and all the tab widths would be incorrect.

2. But then you can no longer copy and folders!

[Lefteous]

2JohnFredC

Need new commands: cm_ToggleLeftTree and cm_ToggleRightTree. I looked through the new include file and couldn't find these commands. These are an absolute must. Without them I probably won't use the trees at all.

How would you use these commands? The current shortcut is Shift+Tab (tree corresponding to current file list window or when using the single tree).
Although the current focus implementation is fine for me these commands would definitely not hurt.

[JohnFredC]

There should be a command to toggle the visibility (not focus) of the tree in the left panel. There also should be command to toggle the visibility (not focus) of the tree in the right panel.

Two commands: either cm_ToggleRightTree and cmd_ToggleLeftTree or cm_LeftToggleTree and cm_RightToggleTree. Doesn't matter what the commands are called.

Currently in B1, TC offers either dual folder trees, a "separate" tree, or no trees. (There's even a mode with 4 folder trees and no files! Have you found that one yet? I'll assume that oddity will get cleaned up before RC1.)

Left and right trees should belong to the tabs that are active in the left and right panels. Each tab should appear to have its own tree that the user can hide or show as needed.

[Lefteous]

2JohnFredC
Sorry I misunderstood you for unknown reasons

[JohnFredC]

1. Sorry, it's not possible - TC would become asymmetric, and all the tab widths would be incorrect.

2. But then you can no longer copy and folders!

1. No. That's a statement about internal implementation schema. GUI design should drive the internal implementation code, not the other way around. Start with the "way it should work", then write code to implement that.

2. No. The problem in B1 is that the tree functionality is not implemented completely. If the tree was a fully functional folder tree that all users of trees will expect, then hiding the folders in the file panel simplifies the interface. Naturally, it should be a toggle.

I recognize that many of the issues with the folder trees are related to the legacy code hiding in TC for many years and that other limitations are related to the need for TC to keep track of and report the "focus" for the keyboard-centric users (who appear to be the majority in the forum).

But these are issues of GUI design that have been addressed adequately over and over again in other software including many competitors of TC.

A good approach would be to use the other software, see what design decisions were implemented, then IMPROVE them in TC.

Sorry to be so critical. I really looked forward to the folder trees, but can't use them they way they are now.

[Mikefield]

I agree with JohnFredC, to toggle the tree would be very nice.
Also it would be fine too, to have the 2nd tree on the right side,
not in the middle of the main window.

mf

[sqa_wizard]

Also it would be fine too, to have the 2nd tree on the right side,
not in the middle of the main window.

Sounds good. This way the file list would be "surrounded" by trees, instead of interrupted by tree.
It would allow you to fully use the new "alternate line color" feature to compare left/right panel line by line with both trees on.

[Stitscher]

Also it would be fine too, to have the 2nd tree on the right side,
not in the middle of the main window.

Sounds good. This way the file list would be "surrounded" by trees, instead of interrupted by tree.
It would allow you to fully use the new "alternate line color" feature to compare left/right panel line by line with both trees on.

I second this request.
To have the 2nd tree on the right side would be very useful.

Stitscher

[Stitscher]

Also it would be fine too, to have the 2nd tree on the right side,
not in the middle of the main window.

Sounds good. This way the file list would be "surrounded" by trees, instead of interrupted by tree.
It would allow you to fully use the new "alternate line color" feature to compare left/right panel line by line with both trees on.

I second this request.
To have the 2nd tree on the right side would be very useful.

Stitscher

Little bump.

The more I use the new 2nd tree, the more I need it on the right side of the panel. I think that would make it easier and more intuitive to operate.

Stitscher

[Mikefield]

It's not changed in beta 2, the second tree is still on the left side.

@Mr Ghisler, is there a chance until the release to put the 2nd tree on the right side of the panel?

mf

[ghisler(Author)]

Maybe I will add it as an option, but not as the default.

[Stitscher]

Thanks.

Stitscher

[Mikefield]

Maybe I will add it as an option, but not as the default.

Still missing in beta3.

mf

[JohnFredC]

More importantly, Delete still isn't available for folders in the tree and Delete is STILL missing from the tree context menu...!?!

I just don't understand the reasoning behind leaving it out.

One kind of task I do is to browse through the tree from one folder to the next, looking at each folder's contents (stream-ripped mp3s) in the file panel. Frequently after inspecting the files, I want to delete the active folder.

To do that, in TC7 I have to:

0. Use the tree to find/select a folder to delete
1. Navigate to the parent folder
2. Select the same folder again
3. Delete the folder using standard methods
4. Return to where I was in the tree
5. (hmmm, where was I?)
6. Continue.

When there are hundreds of folders, this is more than inefficent, it's ridiculous!

The purpose of the tree is to make all this easier... and it would, if Delete were in the tree context menu or the Delete action applied to the selected folder in the tree.

If Delete from the tree was available, the task sequence becomes:

0. Use the tree to find/select a folder to delete
1. Delete the folder the folder using standard methods
2. TC at this point should select the next folder in the tree
3. Continue

Please put Delete back into the Tree context menu and/or enable the Delete button when the tree is active.... !!!! Please?