ok, i guess what i'm trying to say is that tabs are not, and never have been, a good visual metaphor for large lists. however they are handled, they become unintuitive and ugly. i have *no* problem whatsoever using tabs when i know they are all visible. i was just throwing an idea around for when tabs aren't viable (ie - as soon as there are too many for your workspace)
disadvantages of too may tabs:
- several keystrokes/mouseclicks to reach hidden tab - we must shift focus to new tab (thereby hiding other tabs) - can't currently drag from end of tabs to beginning (mats addresses this, though) - most tab-bar solutions (ie, drop-down menus) are counter-intuitive because filenames are still hidden from the user's view - so they can't comprehend at a glance whether the tab they want is available or not
advantages of file-list:
- keeps usual keyboard nav, but requires less mouseclicks - "spotlight" filter could be applied to *all* open files - expandable list area means the user can easily see at-a-glance what files are open even in very long lists. - easily maintains drag re-ordering even if you've scrolled to the bottom of the list and want to drag back to the top
anyway - as i say, it's just my preference and i would see it only as an option for the user. :-)
Mats Persson wrote:
Here's my two cent's worth of input.
On 4 Jan 2005, at 09:35, Sam Andrews wrote:
i often work with pretty bloated projects, and the tabs don't really work for me, either. my personal preference would be for a list of active files displayed in the drawer - so split the drawer between that and the project file list, as shown in this mockup: http://dev.samandrews.com/misc/tm1.jpg (121k jpg)
Sam, please accept my apologies as it's not personal, but I have to pass on the following comment to your proposal.
Allan, I sincerely beg you - on my knees, hands firmly clasped - to PLEASE NOT implement anything like that in TM. It reeks of BBEdit, and is in my mind a completely flawed implementation.
A far better improvement on the current implementation would - in my mind at least - be a larger sized overflow ">>" tab at the end of the bar to handle the overflow files. The size of this tab should be of dynamic size to fill the space between the last normal tab and the end of window, and big enough to display the same widgets & text as a normal tab, but also a [ N ] (number of files in tab).
On selecting the tab - via mouse or keyboard - a pop-down tab menu would appear, with the standard tab layout ( ie close widget + file name). Using the normal tab navigation key commands, would highlight the selected file in the pop-down menu, and then the top tab text would display the active file name. Think HTML Select pop-up menu functionality.
If you wish to move a file from the overflow tab, then you would just move it as a normal tab, and the last normal tab in the existing tab bar moves into the overflow tab. (Hope you followed me there ? )
While I'm at it. How difficult would it be to implement the following: Apple+Alt+Shift+ <left/right arrow> to actually move the order of tabs via the keyboard ???
To me that solves much of the problems, as the overflow tabs follow the same functionality as normal tabs. Love to hear your views.
On 2 Jan 2005, at 19:55, Allan Odgaard wrote:
So a group is configured how? And should it be possible to do ad hoc grouping by e.g. dropping one tab on another tab (to make it into a group), and exactly how does a group affect navigation?
I too like the idea of group based tabs, where all .css files were stored in one single tab and so on, but I can't see how that implementation would work any better than the current implementation. What happens when you select a file in a group tab, does it take over the visibility of that tab, or open in a new tab ?? How would you navigate this group tab scenario with the keyboard ??
On 4 Jan 2005, at 06:53, Allan Odgaard wrote:
Tabs allow me to quickly navigate in this hot set with keys (the visual aspect of them is negligible), and I can re-arrange them to have two files I often switch between next to each other. Locating the file in the project drawer is probably 1-5 seconds compared to 0.1-0.8 seconds switching to it using cmd-option left/right.
Absolutely! Tabs rocks, and it is the way to go. No doubt!!
My hot set is rarely >5 and my TextMate project contains >100 sources alone. And the drawer is certainly more work to use.
I too close down unused files as soon as I've stopped working on them, as it's relatively quick and easy to open them up again when needed. But I guess we are dealing with personal habits & 'discipline' here.
Kind regards,
Mats
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate