On Jan 4, 2005, at 12:04 PM, Xavier Noria wrote:
On Jan 4, 2005, at 10:35 AM, 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)
to further extend the functionality of this view, it might be desirable to indicate some basic metadata for open files such as last saved, number of bookmarks (useful if you use bookmarks to track your to-do items) and so forth. i think the spotlight-esque filter as xavier proposed could also be very useful.
I second that proposal. In my daily experience the one row of tabs (both in TextMate and Eclipse) just adds noise because you have just a handful of opened files there, whereas I tipically have a lot more. Because of that the tab selector is in fact useless most of the time, and the interface it enforces makes looking for an opened file not in the tabs something exceptional, I mean, it is not the default interface, the easy one, but it is the one I normally need.
I have to add something there.
If I think further I believe the distinction between opened files and files in the project is artificial. It is a traditional distinction, but tradition sometimes can be improved as iTunes did. I think this intuition goes in the line of Fred's ideas.
I think what I really would like would be to eliminate that distinction from the end-user interface. For instance, just off the top of my head. There could be two ways to select a file in a project:
1. Project-wide filtered textfield (shortcut/menu selection) 2. Selection in the drawer (mouse/keyboard)
The editor then would take care of managing resources. It could have a hidden pool of opened files, so that the end user does not care whether the file is being opened or recovered from memory. The drawer could show files modified and not saved with an icon as Eclipse does for errors for instance (if there's an error in a file the icon is propagated to all the ancestors in the tree, so that you see it even if its branch is not expanded).
Then the editor could have configurable parameters, maximum of files in memory, saved files not consulted after certain expiration could be closed until next request, ....
Well, just some non-polished ideas thrown to the thread.
-- fxn