[TxMt] how do you close excess tabbed files?

[Mats Persson]

A few further points:

And No, Sam, I'm not in a vendetta against you. : )

On 4 Jan 2005, at 11:11, Sam Andrews wrote:
> disadvantages of too may tabs:
> - several keystrokes/mouseclicks to reach hidden tab

Keystrokes: This will be the case with every implementation I can think 
of, so I can see no advantage in your proposed design / file list.

Mouse clicks: In a BBEdit like list, I guess we could easily click on 
the chosen file (tab), but we could do the same with my implementation 
idea. Think folder of bookmarks in Safari bookmarks bar. Click-hold and 
select file/bookmark.

> - we must shift focus to new tab (thereby hiding other tabs)

Might be misunderstanding you here, but isn't that the case anyway ? 
Alternatively, this could (??) be a preferences option that would 
indicate how to handle the overflow-tab click event, display selected 
overflow file or not.

> - 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

I don't know about your screen, but I've got a lot more horizontal 
space than I have vertical. (iMac 20"), and I am already toggling 
folders in the Project Drawer, so I can't see how I - or anyone - could 
possibly fit in open files and file hierarchy into the Project Drawer. 
It's a UI disaster in my mind.

As for a single glance view of open files. Normal tabs shows clearly, 
so we just need the overflow tab to work better than current 
implementation. Perhaps  we could have Apple+Alt+[plus/equals] to 
display the overflow-tabs menu ? If you use the mouse, then you can 
just click on the tab and see all open files within it.


> advantages of file-list:
> - keeps usual keyboard nav, but requires less mouseclicks

Not getting this point at all, but a file list is no easier to click 
through than tabs. Might require less mouse movement, but that's it.

> - "spotlight" filter could be applied to *all* open files

Sledgehammer and nut comes to mind with regards to 'spotlight-ing' open 
files. If you need to search your open files, then you have too many 
open.

As for 'spotlighting' / smart groups in the Project Drawer, well, 
that's a different issue.


As Allan is well aware of, the Project Drawer could be improved in 
various areas, and will be for 1.2 (??)  Perhaps a better way to 
display open files for some, would be - as I believe has been proposed 
before - discretely background-highlighting opened files in the Project 
Drawer. (sort of like current file icon changes on un-saved files now). 
That ought to give a better alternative to those that don't like the 
tabs.



On 4 Jan 2005, at 16:37, Allan Odgaard wrote in response to Wayne 
Larsen:
>> I agree with this.  I am amazed at (and impressed by!)  those of you 
>> who only work with several files at one time
> Clearly this must be task-dependent. The distinction is not really 
> open files for me but more like 'active' files.
>
> So for the next hour or so, I'll have these 5 files “open” and forget 
> about the rest of the project (which contains hundreds of files in a 
> hierarchical structure).

As a general point on the number of open files, which is really at the 
root of this 'problem'/thread.

I guess we all have our different ways of working and I may not 
understand the structure of everyone's work, but I would still hazard 
the guess, that most developers only work on 1-5 related files at any 
given time. I have found that I too end up with a lot of open files, 
but have started to learn the process of doing the work required in the 
file and then closing it down. I can always open it from the Project 
Drawer within 1-5 seconds, and trust me, I spend a lot more time 
thinking about the code I am about to write than I spend on re-opening 
files, so a saving of N seconds here or there is really a mosquito fart 
in outer space.

The thing about TM is that as you work with the program and it's 
inherent limitations you can reform your working practices, often for 
the better. I and many others 'complained' about the lack of 
code-hinting for our chosen language - and it would still be good 
sometimes - but now I have created a largish collection of snippets 
that does my work much quicker and better than any other code-hinting 
solution I'm aware of.  Hell, I've even rolled my own basic CVS 
functionality into TM. (will share later this week when I'm sure 
everything is OK for public consumption)



Kind regards,

Mats