Tab browsing

We welcome any suggestions for new features or improvements in Altap Salamander. Please post one suggestion per report.
JohnFredC
Posts: 162
Joined: 10 Dec 2005, 15:44

Post by JohnFredC » 27 Mar 2006, 20:32

Jan Rysavy wrote:
Could you be more specific?
For a start, here are two images of a competitor's product (SC) showing a) the tab context menu and b) a tab property dialog:

a) Tab context menu
Image

b) Tab property dialog

Image

The property dialog in particular addresses nearly all of the options it would be good to see in a Salamander implementation of tabs.

The window behind the context menu is the left pane of a two-pane commander. Notice also that the selected tab ("F_Laptop") displays a tree in addition to a detailed view. In this product, each tab may display a private tree. Also, each tab remembers every particular of itself, including, tree visibility, details/thumbs etc, sorting, filters, and properties settings.

See also that in the row above the tabs is another row of tabs. "Folder Tabs" are what you expect. A "File Container" is a virtual folder that contains links to the files you put in it (instead of the originals). This feature is very convenient for collecting files from many different folders and displaying them all in one place. In this tool you may set up any number of "file containers", each on its own tab.

I love this way of working. Hugely productive for those of us with large and complicated folder structures.
Last edited by JohnFredC on 19 May 2006, 15:38, edited 1 time in total.
Mouse-centric, Registered

Guest

So where are we with tabs?

Post by Guest » 19 May 2006, 09:21

I know it's in the road map, but it's the ONE thing that's keeping me from using this product on a regular basis. Just by having tab capability, Total Commander completely beats Servant Salamander.

I use tabbed directory browsing all the time, so much in fact, that it feels strange not to have them, almost handicapped.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5196
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Re: So where are we with tabs?

Post by Jan Rysavy » 19 May 2006, 09:35

Anonymous wrote:I know it's in the road map, but it's the ONE thing that's keeping me from using this product on a regular basis. Just by having tab capability, Total Commander completely beats Servant Salamander.

I use tabbed directory browsing all the time, so much in fact, that it feels strange not to have them, almost handicapped.
Could you describe what should the IDEAL tabs implementation look like?

JohnFredC
Posts: 162
Joined: 10 Dec 2005, 15:44

Post by JohnFredC » 19 May 2006, 19:14

OK... here are some things important to me in an "IDEAL" tab implementation. There should be enough here to promote discussion and/or get the Salamander team started. Does not address virtual folders, which I also hope for.

Options for "all tabs" (via global Options dialog)
Appearance Group
-Toggle: tab row at top or at bottom
-Toggle: Tab row always on or tabs off if only one tab
-Toggle: Enable/Disable "Wrap tabs"
-Value: Tab "fixed width" setting (0 turns off)
-Toggle: Enable/Disable "New tab button" (as in IE 7)
-Option: "New tab button" displays itself Left or Right (default)
-Option: A "New tab" appears left, right, or adjacent to current tab (default)
-Toggle: Display close button ("x") on tab always (only on mouse over otherwise)

Behavior Group
Option group: If navigating inside a locked tab (see below) 3 options:
- Option 1: "Start new tab"
- Option 2: "Go to tab:"
- Value: Tab to activate if Option 2 (combo listing available tabs)
- Option 3: Do nothing
- Toggle: Enable/Disable "Save tabs on exit" (Left side)
- Toggle: Enable/Disable "Save tabs on exit" (Right side)

Tab Startup Group
Option group: Salamander startup
- Option 1: Restore tabs on startup
- Option 2: Always open following tab groups:
- Value: Tab group file to display on left when Salamander starts (combo + browser)
- Value: Tab group file to display on right when Salamander starts (combo + browser)
- Value: "New tab" default path left side (combo populated by favorites + browser button)
- Value: "New tab" default path left side (combo populated by favorites + browser button)
- Toggle: Disable/enable folder tree in new tab panel
- Toggle: Tab's panel view persists (icons, thumbs, etc)
- Value: "New tab" default panel view combo
- Toggle: Tab filter (*.doc, etc) persists
- Value: "New tab" default filter (combo with recent filters and adjacent "New" button opening filter dialog)
- Toggle: Tab column layout / sort order persists
- Value: Default Tab column layout / sort order (button to designer???))

Miscellaney Group
- Value: Default Path location to save tab files (plus browser button)

Options for "each" tab (via tab context menu->"Tab Properties")
Navigation group
- Toggle: Enable/Disable navigate "up" the folder hierarchy
- Toggle: Enable/Disable navigate "down" the folder hierarchy
- Toggle: Enable/Disable Return to tab root on activate
- Toggle: Enable/Disable Refresh on activate
Appearance Group
- Toggle: Display folder tree inside this tab
- Value: Path displayed by this tab (combo)
- Value: Tab Pairing: Tab/path to display simultaneously in opposite panel (not sure how this would work)
- Toggle: Enable/Disable tab title lock (Show current folder name by default)
- Value: Tab title text if tab title lock enabled
- Toggle: Enable tab color
- Value: Tab color picker
- Toggle: Enable/Disable tab icon
- Value: Select icon file with browser
- Toggle: Lock relative left/right position of tab when possible (such as always 1st tab on left or right)
- Toggle: Tab's panel view persists (icons, thumbs, etc)
- Toggle: Tab filter (*.doc, etc) persists
- Toggle: Tab column layout / sort order persists
- Toggle: Quickview persists (that is, restore pre-existing linked quickview when re-entering tab)
- Option group: Quickview Display
- Option 1: Display Quickview in new tab in opposite panel
- Value: Vertical divider position in % for opposite panel Quickview
- Value: Name of Quickview tab in opposite panel (defaults to new tab with filename)
- Option 2: Divide this panel and display Quickview inside this tab
- Toggle: Display Quickview at top (default to bottom) if Option 2
- Value: Horizontal divider position in % for "in tab" Quickview


Tab Context Menu
-New tab
-Duplicate tab
-Duplicate tab to opposite panel
-Close tab
-Close all tabs
-Refresh contents
-Save tab group
-Save tab group as...
-Open tab group
-Tab properties


Tab Interactivity/Behavior
- Drag & drop tabs to rearrange
- Drag & drop tabs to copy/move to other panel (left button copy, right button move)
- Close tab with middle click
- Drag and drop file selection to tab (left button copy, right button move)
- Short cut key for new tab in current panel
- Short cut key for close tab
- When attempting to navigate in a locked tab (see above) either do nothing, start a new tab, or go to a predefined tab (see options above)

Other Stuff
- Display quickviews in new tabs
- Pair file display tab (on one side) with Quickview tab (on other side) and make the relationship persistable.
- Enable Quickview panel as additional viewer pane INSIDE a single tab
- Allow "standalone" persistent Quickview tabs
- Show/hide tree INSIDE tab
- Naturally all plugins should be available inside a Quickview tab.

One of the great things about TC is that I can open a console command prompt or a text editor INSIDE a persistent tab...
Mouse-centric, Registered

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5196
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Post by Jan Rysavy » 19 May 2006, 20:04

Many thanks JohnFredC, your work is really appreciated!

Tomcat
Posts: 44
Joined: 28 Apr 2006, 17:21

Post by Tomcat » 21 May 2006, 22:19

I haven’t used tabbed file management yet (as I am a devoted Sala disciple :D ) but I think that it could be really useful. So I will not try to depict an ideal implementation (as I lack experience) but what would be an ideal start for me as a newbie on tabbed browsing.

Credits go to JohnFredC, jis, mazy(in this thread), TC, SC and Firefox for inspiration.

Let’s start with my

Guiding principles
- Intuitive (the first user’s guess about the behavior should be right; well, at least the second)
- Consistent (tabbed browsing should be consistent with the behavior of panel browsing and other features in SS)
- Minimized configuration/options (if there is one intuitive approach, then take that, even if some users might want it differently)
- Equal or better than competitors implementation (not that I am concerned about that)
- No annoyances (well, you could say this covers it all)

So then, let’s start with the

Architecture
I found the following related statements on the roadmap
- Tree view, Quick view, Information view.
- Browsing network neighborhood in panel.
- Folders browser in panel (My Computer, Desktop, Control Panel, Recycle Bin, etc.)
So there will be more than directories in panels (very nice, btw). There are also some ideas out about workspacesetc., therefore I would like to
1) handle a tab group as a group of panels, not as a group of directories
This would have the following consequences
- Enable tabbed browsing for all types of folders not only for directories
- Allow to freely mix directories, quick views, tree views, virtual folders etc. in a tab group
- Everything that works for a panel now should work for a tab (e.g. configuration)

And another statement from the roadmap
- Structured and unlimited Hot Paths
That rang a bell and I remembered the Firefox implementation, so why not
2) Integrate tab group management with hot path management and treat a tab group as a named collection of hot paths
This would have some interesting implications. If fully implemented it should be possible to have a tab group of tab groups ...

Out of the first two follows a third architectural request:
3) Expand hot paths to hot panels
That means that hot paths/panels should remember filters, sort orders, display style etc. (like panels do today, when re-establishing last state on start-up of Sala)

Next step is

General Behaviour and Display
- Save tab configuration on shut-down. Re-open last state on start-up (consistent with behavior of panels in SS2.5)
- Show tab-bar at top (Windows GUI style)
- Add new tab to the right of tab list (there I would expect a new tab)
- Any directory selection per hot path, directory change etc. should only affect the active tab (should not replace whole tab group, somehow obvious I think)
- Remember tab configuration like sorting, filter, layout etc. (follows directly out of the architecture)
- Tab name should equal the folder name (dynamic). Once the name has been edited manually it should become static.

Now to the

User Interface
I am a mouse-centric user, so I will focus on that part:
- Allow drag and drop to arrange tabs (even across panels)
- Allow drag and drop to pull folders to the tab bar (also cross-panel)
- Click on directory with middle mouse button adds the folder to the tab group of the panel (pressing also CTRL adds to other panel’s tab group)
- Show tab with left button
- Close tab with middle button
- Invoke context menu of tab with right button
- Rotate with mouse wheel to switch tabs when the pointer is over tabs bar
- When the pointer isn't over the tab bar, press the right mouse button and rotate with mouse wheel to switch tabs (suppressing context menu after release of right button)
- Allow inline editing of tab name with slow double click (like Excel does with worksheets and Sala/Explorer with files/directories)
- Dragging files and directories to a tab should work as if dragged to the panel itself (copy, move or create depending on Shift-, Ctrl-key and drive), the active tab should not change during this operation

Tab Context-menu should contain:
- Close tab
- Close all (other) tabs
- Duplicate tab
- Edit name
- Save tab group

I thought about an intuitive process to bring up the tab bar (if not always on). How about this
- Option in panel context menu like ‘Add to tab group / Show as tab’
- Bring up the tab bar if a directory is dragged to the panel toolbar (now SS switches to that directory, what I can achieve much simpler with double clicking it)

And finally the

Miscellaneous

Required General Options
As stated above only the ones required to avoid major annoyances
- Checkbox: Hide tab bar if only one tab
- Checkbox: Show all tabs in one row

Things to think about but not important for a start
Tab display
Different color / font style (e.g. bold) or icon for a tab if it is
- dynamic or static,
- a directory or something else (registry etc.)
- ???
Tab and tab group pairing
Could be achieved with additional tab specific option:
Option: Open this tab group/hot panel in other panel: (Combo with tab groups/hot panels)
This could become a general option for hot-panels

Navigation thru tabs
Dragging to a tab and holding the button for, let’s say, a second should open that tab to allow dropping on a sub-folder (not a must-have, but would support my workflow. Needs to be optional, I think)
Startup
Especially useful if tab-groups in tab-groups will be possible: A master set of tabs that will be loaded on startup
Option 1: Restore panels on start-up (like described above as the minimum)
Option 2: Open following tab-groups on start-up
Values: Open following tab-group in left panel
Values: Open following tab-group in right panel
Navigation
- Allow to go back to previously selected tab-groups (like now with directories), would allow to navigate in a tab-group hierarchy


Ideas I don’t like
- Please don’t place configuration files in every folder
- Don’t save tab group configuration in extra files (do it in the configuration like hot-paths)

That's it folks. Now it's your turn. And don't dare to come up with a SS 3.0 beta 1 without tabbed browing :lol:

Amended sections in blue
Last edited by Tomcat on 28 May 2006, 21:48, edited 2 times in total.

JohnFredC
Posts: 162
Joined: 10 Dec 2005, 15:44

Post by JohnFredC » 22 May 2006, 01:56

2Tomcat

Wow... now we're talking!

Basically I agree with everything except the request NOT to allow config files in folders. I like the idea of separate config files per folder (or at least for some folder "types"), though requiring them would be a stretch. Perhaps an option to cause Salmander to first look in the folder for a config file, then if it doesn't find one, look in the centralized config data structures it maintains. The advantage of individual folder config files is that it reduces Salamander's data maintenance burden. Delete a folder (with any tool), its config is automatically deleted. Otherwise, Salamander will have to synchronize folders from time to time and expunge orphan configurations.

In DOpus, a user can assign a type to any folder and Dopus will remember it, reconfiguring itself to display columns etc associated (in a global "define folder type" attributes dialog) with the assigned type whenever the user navigates to the folder. However, for folders that don't have user-assigned types, DOpus optionally uses an algorithm to examine the population of files in a folder and assign a pre-defined view associated with the predominant filetype (images, spreadsheets, music, etc). Works well (though DOpus itself is very frustrating to use).
handle a tab group as a group of panels, not as a group of directories
Which is more central to a tab: filepath (directory) or view (thumbs, details, sorts, filters, etc)? Well it depends. Sometimes it's an extra step to switch to thumbs (for instance) and sometimes it's an extra step to navigate in a panel already displaying thumbs (again, for instance). This bears much more discussion.

I think a key to resolving this issue may lie in 1. Persistence of individual tab view/folder/filter/sort, etc. (see above) and 2) how Salamander handles the tab caption. For instance, it would be nice to have tab captioned "Thumbs" that never changed its caption, that always preserved thumbs view, but did not restrict navigation in any way. This approach could be realized in the tab property panel (see my prior post) by enabling tab title lock, entering a title ("Thumbs"), leaving the 2 navigation lock toggles (up and down) off, and checking the persist tab view toggle when thumbs are displayed.
If fully implemented it should be possible to have a tab group of tab groups ...
I thought about this too. One approach would be an option to have TWO "tab bars" in each panel, one above the other. The top one would be the "tab group" tabs, the bottom one the tabs associated with the selected tab group. Speed Commander does something like this, but in a very incomplete and frustrating fashion: its "tab group" tab bar only has two tabs: selecting one displays folder tabs in the individual tab area, the other displays the "file containers" tabs (SC's excellent - but incomplete- approach to virtual folders). Plenty of room on the SC "group" tab bar for more than two tabs/groups.

I hope others also contribute to this thread.
Mouse-centric, Registered

Tomcat
Posts: 44
Joined: 28 Apr 2006, 17:21

Post by Tomcat » 23 May 2006, 23:02

2JohnFredC Thanks for the feedback. Some comments to it:
Basically I agree with everything except the request NOT to allow config files in folders.
I see the potential benefit of it but software that scatters little files in numerous directories falls in my personal annoyance category (I like Win Media Players ability to display CD-covers but I hate it for the fact that it stores them next to the MP3-files). I also use 99.5% of the time the detailed view so it has little benefit to me.
Folder configuration in general may warrant an extra thread as it would also affect un-tabbed browings.
Which is more central to a tab: filepath (directory) or view (thumbs, details, sorts, filters, etc)?
Just to make sure that we are on the same page: For me, a panel configuration consists of the display style and the displayed path, so my answer would be: It's both.
If fully implemented it should be possible to have a tab group of tab groups ...
I thought about this too. One approach would be an option to have TWO "tab bars" in each panel, one above the other. The top one would be the "tab group" tabs, the bottom one the tabs associated with the selected tab group.
I have a different implementation in mind. I would display tabs and tab groups in one tab row, like directories and files are displayed in one panel. Clicking on a tab-group tab (gig) would open that tab-group. This would allow unlimited levels of tabs and tab groups. If there would also be an option to move up in that hierarchy then the user could navigate in an unlimited tab group tree like now in a directory tree. Well ..., this may need an example.

So imagine you have a tab-row like this (tab group tabs in italic)
/ Work / Downloads / My Music /
Clicking the Downloads or My Music tab would open that directory, but clicking on the Work tab-group tab would replace the current tab group for that panel with the children of Work, e.g.
/ Projects / Travel Requests / Data Reports. In this example Projects is again a tab group.

I may edit my earlier post tomorrow to include some features to support this idea ...

Tomcat
Posts: 44
Joined: 28 Apr 2006, 17:21

Post by Tomcat » 28 May 2006, 21:43

I have amended my earlier post to keep the concept together.

2JohnFredC can you please describe the use-cases behind locked panels? I cannot imagine what this feature is for. Is it just a way to stop a user from navigating in tabs he/she does not want to?

JohnFredC
Posts: 162
Joined: 10 Dec 2005, 15:44

Post by JohnFredC » 28 May 2006, 23:50

2Tomcat
describe the use-cases behind locked panels
I'll try!

First, by "lock" I mean to lock "navigation" within the tab. Locking a tab for navigation preserves the integrity of the tab's path definition by preventing it from changing as the result of inadvertent user action. There are two circumstances:

1. UP from the tab's path location (to a parent folder or drive, or to a location on another drive).

2. DOWN into a subfolder of the tab's path location.

UP

Locking the UP navigation creates an artificial "root" similar to a SUBST drive. Clicking the "\" button while in an UP tab should take me to the tab root.

For instance, each of my programming projects is a tree of folders beneath a single folder that is named for the project. I could setup an UP-locked tab for each project, each pointed at the appropriate "root" folder for the project. With "go to base folder with every activation" turned on, entering the tab automatically navigates me to the top folder for the selected project, into which I can navigate freely. I would also want the "\" button behavior modified to return me to the tab root instead of the drive root. Further, if I displayed the folder tree in an UP-locked panel, I might want the tree's root to be the tab's root. Not sure though, have to think about that.

An attempt to navigate up (by clicking "^..") would instantly send me to my designated default tab (if I had set the options for this), perhaps with a notifier or indicator. This is good, because I would setup my default tab as a sort of "scratch pad". I could continue my navigation activities in the default tab without interruption and the location pointed to by the original tab would be preserved, ready for next time.

DOWN

The argument for a "DOWN" lock is harder to put except in conjunction with an UP lock. Locking both UP and DOWN creates a navigation-protected view of a single folder, naturally one that was never intended for subfolders.

A tab set up as a "recursive view" would behave automatically act as if both UP and DOWN were locked. Woops, what's recursive view? It's called "flat view" in TC and "branch view" in SC, and means to flatten the folder hierarchy and show all files in the tree in one panel. For instance, navigating to the root of a drive, setting a filter of *.mp3 and turning on "flat" or "branch" or "recursive" view would show all mp3s on the drive in one view... great for eyeballing duplicates, etc.

OTHER THOUGHTS

My personal tab setup schema would have two unlocked tabs at the left of each panel, both with embedded folder trees, followed by the other tabs of my daily use. I would designate the first one on the left of each panel as my "default" tab that would activate when I attempted navigation in a locked direction in some other tab. The second tab on the left of each panel would be a second "scratch pad" tab. I have experimented somewhat and found that two "scratch pad" tabs on each side is enough, all the rest of the tabs could be UP locked (at least) to their respective root folders.

An important part of this "scratch pad" tab approach would be the ease at which new tabs could be created from the folder location of the scratch (or any) tab. A key combination, a context menu "new tab focused here" or something like that would be needed.

None of these ideas are mine, by the way, they already exist to a greater or lesser extent in other products.
Mouse-centric, Registered

Post Reply