cm_GoToRoot inside the separate tree

roentgen · Post by *roentgen » 2006-12-19, 17:19 UTC

The cursor is inside the tree.

- With ONE separate tree:
cm_GoToRoot hides the cursor, pressing key down has no effect for a while. On the sixth press the file list gets focus.

- With TWO separate trees:
After cm_GoToRoot the cursor instantly jumps to the file list for the specified panel, but still this isn't right as I'd expect the cursor to remain into the tree.

Post by *petermad » 2006-12-19, 17:57 UTC

Confirmed.

The same thing applies to cm_GoToParent

Flint · Post by *Flint » 2006-12-19, 17:58 UTC

Confirm.

Post by *petermad » 2007-01-12, 16:40 UTC

Not changed in TC7pb3...

Post by *ghisler(Author) » 2007-01-12, 19:43 UTC

What should happen in your opinion? cm_gotoroot makes no sense within the tree...

Post by *petermad » 2007-01-13, 00:00 UTC

Well it should do as it does now - move the cursor to the drive letter of the current drive in the tree - BUT the cursor should be active - not just the inactive cursor (with the background 2 color) - that is: the separate tree should keep its focus.

roentgen · Post by *roentgen » 2007-01-13, 16:19 UTC

The problem is more general than this.
Most command in TC are designed to act upon the file lists.
When the user executes a command in the tree he expects things like: focus should stay inside the tree, the command should act upon the selected dir inside the tree, etc, which is not currently happening.

JohnFredC · Post by *JohnFredC » 2007-01-13, 18:10 UTC

ghisler(Author) wrote:cm_gotoroot makes no sense within the tree...

That's a programmer's logic talking. A user's practical point of view would be:

If a folder is highlighted in the tree, cm_gotoroot should go to the root of the drive containing the folder.

If the root of the drive is highlighted in the tree, then cm_gotoroot would go to the root of the drive list, ie. My Computer.

If My Computer is highlighted in the tree, then cm_gotoroot should go to root of My Computer, ie. Desktop.

I am baffled why this is even an issue for discussion!

cm_gotoroot should mean:

Go to the node that represents the root of the domain membership of the selected node. Simply put: the parent node ...except in the special case: when the selected node is a subnode, that is, the child of a child of a... cm_gotoroot should mean go to the root of the subnode's membership domain. For example, in the case of a file system subfolder ("subnode") having been selected, that is the drive root node NOT the owner node/parent folder.

This general schema can apply no matter what sort of items are in the tree.

In all cases, IMHO the focus should remain in the tree and NOT migrate to the file panel.

Post by *petermad » 2007-01-13, 18:15 UTC

2JohnFredC

I can only agree 100% to what you have so eloquently written abowe.

Lefteous · Post by *Lefteous » 2007-01-13, 18:24 UTC

2JohnFredC

That's a programmer's logic talking.

The logic behind this is that the tree is so limited that support for this command wouldn't sort out the mess

Post by *ghisler(Author) » 2007-01-14, 14:19 UTC

Sorry, there are 1000s of commands, it would take ages to make them all work with the separate tree...

Lefteous · Post by *Lefteous » 2007-01-14, 14:24 UTC

2ghisler(Author)

Sorry, there are 1000s of commands, it would take ages to make them all work with the separate tree...

I well I guess you need to set priorities and users pointed you to some most wanted commands.

JohnFredC · Post by *JohnFredC » 2007-01-14, 14:52 UTC

The problems with the TC 7 tree implementation are indicative that the evolution of TC is approaching (or already at) a critical juncture which will determine its future path: Does TC remain hand-tuned private code? Or: has TC begun to face a wall of programming effort that no single developer has the resources to scale?

Benefits of programming a tree from scratch: possibly smaller size of code, ability to completely customize behavior, appearance, etc.

Costs of programming a tree from scratch:

there are 1000s of commands, it would take ages to make them all work with the separate tree...

Does this mean that the TC trees will remain functional orphans? If so, why waste all that time and energy on putting trees into TC in the first place then? I personally don't find their current limited and quirky behavior as navigation tools compelling enough to counter-balance their incompleteness. Does anyone else?

3rd party trees have had many years to evolve into stable, fast, useful, full-featured controls. The amount of man-hours needed to duplicate the functionality of these 3rd party controls is staggering, especially for one individual with so much already on his plate. But the public has been trained by myriads of other software to expect certain behaviors in trees and will be "disappointed" by the current TC approach.

My advice: due-diligence research into 3rd party tree controls, find one suitable, purchase the code, combine it with TC, and don't look back. Same thing for the file panels, toolbar, and menus.

TC is already over the 1.44 diskette limit. Time to move forward.

Lefteous · Post by *Lefteous » 2007-01-14, 17:37 UTC

My advice: due-diligence research into 3rd party tree controls, find one suitable, purchase the code, combine it with TC, and don't look back. Same thing for the file panels, toolbar, and menus.

Hm I guess you misunderstood that. It's not about the controls abilities it's about supporting TC commands there. That's nothing you can buy.

JohnFredC · Post by *JohnFredC » 2007-01-14, 17:45 UTC

Honestly I don't understand why you are a TC user.

My posts are frequently quite strong (perhaps increasingly so) and I understand why you may feel that way.

I continue to use TC because (everyone else here knows from personal experience, not hype) TC is the fastest, most reliable, most useful, most stable, and most extensible such tool available! And the ONLY one I fully trust for my critical file management. TC is the only such tool I have used that has never lost a file.

But that's not to say TC can't get better... which is my main selfish purpose in posting here: to promote enhancements that would increase my productive use of TC.

I use TC all day long every day and keep bumping up against navigation/selection/automation situations that are much better handled by some competing products... many of which I have also paid for and have attempted to use instead of TC, but have largely abandoned for various reasons (Salamander doesn't support trees or folder tabs, SpeedCommander -great otherwise- is SLOW and disastrously unreliable, 2xplorer doesn't allow me to work the way I want, DOpus is just too... much? And the rest (too many to mention) are downhill from there.)

So I observe how each of the competitors implements functions I find useful (or critical) but missing from TC and then try to distill them into simple GUI concepts that are easy to communicate (enabling delete from the tree, or tree visibility per folder tab, for instance) but which have huge cost/benefit ratios for many users, and especially for those who use TC 24/7 as I do.

But when an enhancement which has demonstrable productivity benefits for a whole subclass of loyal and new users (such as fully functional folder trees) is not implemented because it would "take too much time"... well, that speaks volumes about the legacy code environment itself, doesn't it? If the development cost vs user benefit of any proposed new feature is "too expensive" when the productivity benefit of that feature (for many existing and new users) is quite large... well, I tend to read "between the lines".

And sorry, I am not convinced that productive augmentation of the TC GUI (sometimes referred to as "bloat" by others) would necessarily slow TC down. After all, the user is the largest cost component of the productivity equation.

So if my posts seem strongly worded occasionally, it isn't against TC, but rather for its future!