#186 File Tree Suggestions

[Anonymous]

Originally created by: gmiso...@gmail.com

A few early thoughts on the File Tree control, accepting it's a work in progress:

* Be aware the selected item in the tree doesn't show in the dark theme properly yet.

* A Header would be useful on the tree control with some options in it. I suggest icons, for: Up, Prev, Next, Folders/Files, ..., [!]

Up - to go up a level in the file system, from the current folder.

Prev/Next - to switch back and forth between different places recently visited in the tree already.

... - Navigate to a specific folder, using Open File Dialog set to folder mode.

Folders/Files toggle - Toggles file/folder view. This could be done a few ways:

1. The tree could split (with it's own scroll bar) so folders are visible too then files. A horizontal divider could let you portion the vertical spacing between files and folders as you like.

OR
2. It puts the whole tree into a folder view until toggled back into file mode with the icon again.

OR
3. Puts folders inside the tree, before files. So unlike 1. above, there is no split and just one big scroll bar.

In all cases, clicking Folders/Files toggles folders in or out of the tree.

I like options 1. or 3. best. Perhaps 3 just because it seems easier to code but it may require experimentation or more thought to decide for sure.

* ctrl-shift-d could open the panel ensuring folder mode is enabled.

* [!] An icon (pin/lock image maybe) could exist to tell BP if the tree should track the current tab folder or not. By default it should, unless locked.

* A tool tip over the whitespace in the tree should show the current path in the tree. Though the header or [...] or [!] buttons could work too.

* Quite how/if the context menu option changes between views is something to consider here. Command prompt here over a folder is an idea.

* The File Open dialog could populate the default folder from the currently selected folder in tree control. This might conflict with use of the current tab's current folder - so if/which to use is something to consider more. It could perhaps always be used if the pain is open or only used if the tree has focus at the time. Whatever helps alleviate any confusion. It may require experimentation to see which is natural.

* Might be worth checking if the tree control affects performance with sessions, but probably not or a big consideration.

Anyway just some ideas to consider.

[Anonymous]

Originally posted by: tortoisesvn

> * Be aware the selected item in the tree doesn't show in the dark theme properly yet.
shows up for me fine. Can you provide a screenshot on how it looks on your machine?

Why do you want the tree view to split? Folders are shown just fine at the top, then the files. I think that's good enough. And a doubleclick on a folder expands it, showing the files below that folder.
And splitting it would require a lot more space, and space is something we don't really have to waste.

[Anonymous]

Originally posted by: gmiso...@gmail.com

I doesn't have to split, that was just one option I suggested, option 3 is fine too above which proposes not split. But for argument sake splitting can help when space is a premium. It is not always a curse.

For example, when the number of folders is large and you want a file not a folder you don't to have to scroll through the folders first to get the file. Exactly because the viewport is so small it means scrolling is slow because it only scrolls a small amount each time on a 1366x768 display.

With a split, there is no scrolling in that scenario. But experimenting helps if you can, as I said.

But option 3 is fine I think, but with the buttons and file/folder filter I suggested.

My point is that I don't think you necessarily want a tree at all. More a list of folders followed by files and a folder hide filter. Because nesting in a small space isn't fun or arguably that useful for BP.

With nesting, you lurch slowly right as you nest and it takes up valuable space as you go, but why do it if you rarely want to go back to any folder that you left, at your left, or any midpoint in that list. And why do it like that when you do, because re-finding your position up in the folder list can be hard with a lot of scrolling again often, as usually you've already navigated past it a long way for a file you are after. The original folder(s) are often lost out of scroll view.

But with simple list of folders followed by files and a header with the folder filter and the "up" and "prev" and "next" buttons and something showing the current folder path, you get these advantages:

* First, there is no lurching right, you just enter a folder or you don't.

* Next, there is no scrolling past folders because you hide or show folders as you want them.

* You see more, the whole control can be dedicated to files or folders as you like.

* When you want to go back or up, there is no re-finding the folder in the view or any scrolling. To get back you just click the button, be it. up, previous, or forward. Up and back are always in the same place which really helps.

* If you really want a tree, you can right click and open a tree in Windows Explorer. You can have the best of both worlds this way.

Showing the current folder somewhere would be good though so you have a reference point and something you can right click on for operations on the current folder, like svn update. But the control's whitespace can be used for that, it just isn't as obvious.

So for me, overall I don't think a tree adds as much value as a list and Explorer offers a tree if you really need it so why build it twice. Even if you have a tree, the button header and filter helps still though which is my main desire.