i'm sure there's been discussion of this before, but was wondering if there was anyway to add a preference to have the tabs for the open files of a project wrap to multiple lines instead of limiting them to one line and having that dropdown menu on the right show up. i like to see ALL the files i have open at once and can't stand that dropdown. is this possible? it seems the 'tab component' should be able to handle this. i can look into it if you'd like...
thanx! - jamal
Fow what it's worth (not much, likely), I'm a definite -1 on multi-row tabs. The typical MS-style implementation is a UI horror show, as someone alluded to earlier.
Perhaps some kind of indicator in the drawer for open files would be a useful compromise?
(And as long as I've suggested that I'll slip in the suggestion that the drawer items could visually indicate saved/unsaved file state, too -- that's done in many other apps and is quite handy.)
pb
-- Paul Bissex http://e-scribe.com/news/ Northampton MA USA 01061-0847
i don't use the drawer. that's why i'm suggesting a simple CHECKBOX option. if you don't want it, don't check it. and if it drives you nuts NOT to have it, then click it....
On 12/6/05, Paul Bissex paul.bissex@gmail.com wrote:
Fow what it's worth (not much, likely), I'm a definite -1 on multi-row tabs. The typical MS-style implementation is a UI horror show, as someone alluded to earlier.
Perhaps some kind of indicator in the drawer for open files would be a useful compromise?
(And as long as I've suggested that I'll slip in the suggestion that the drawer items could visually indicate saved/unsaved file state, too -- that's done in many other apps and is quite handy.)
pb
-- Paul Bissex http://e-scribe.com/news/ Northampton MA USA 01061-0847
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
On Dec 6, 2005, at 2:38 PM, Jamal Johnson wrote:
i don't use the drawer. that's why i'm suggesting a simple CHECKBOX option. if you don't want it, don't check it. and if it drives you nuts NOT to have it, then click it....
My understanding is that the "multiple rows of tabs" design is a design that is pretty strongly discouraged by the Apple UI guidelines, and certainly not implemented by the system, and not easy to implement by hand either. So before we continue this discussion, please offer us some examples of other applications that do it this way.
What might be more productive is if we each describe how we use the project window, what *particular* operations we want to perform, and why we think a particular pattern would be best. I personally always use the "GoTo File" browser, and never even look at the tabs, unless I work with two particular files, in which case I'd place them next to each other and use option-command arrow keys. So I find no need to have a long list of all the files I have opened, taking up valuable space.
Yes, we *could* have a checkbox to make it an option, provided Allan implements what is a non-trivial construction, but we could do the same with 1500 other options, resulting in a completely chaotic and useless preferences menu. So if you want such an option, you need to make a *very* good usability argument.
Haris
i understand that the apple ui guidlines discourage this kind of paradigm and being an interface engineer myself, in most cases i agree that if you have to have multiple rows of tabs you should try to organize your information in a more efficient way. but these are _guidlines_, not laws to follow. for instance a preference pane should not have multiple rows of tabs (which are the examples of windows apps most people have used as bad design decisions). i've used both windows and linux machines for a long time, before switching to a mac a year and a half ago, and they both offer multiple lines of rows in most cases. but i don't think that just because it's evil microsoft and apple says it's a "bad way to do it" that it's true in all use cases. for text document like applications i definitely don't think it's a bad design decision for the use case of being able to see ALL my documents that i have open with a quick glance. i work on many files in parrallel all the time, and leave files open i know i have things to do in. i'm a neurotic user of Cmd-T to open files, but if the file is already open i'd like to see that it is and not have to jump thru the hoops of opening the "find file" dialog, typing the name of the file and choosing it. it's simply much faster / easier to glance at the tabs and click the one i want, imho.
i'm not a cocoa developer, but language is simply syntax; the concepts are all the same no matter what language you are developing in. with that said, couldn't you extend the NSTabView and create something like a MultiRowNSTabView? in cocoa, i would assume there are some sort of "layout" controls. let's say you could use a "table" of sorts to wrap the TabView. then couldn't you get the width's of the tabs (NSTabViewItem i take it) and figure out if the one you want to add is going to make it overflow? if it is, add another "row" to the table and add another MultiRowNSTabView? like i said, i'm not a cocoa developer but seems like the concept could definitely work. you would probably be limited to dragging tabs between seperate MultiRowNSTabView however.
anyway, in conclusion: yes, i agree that in some cases it is a "bad implementation", but in certain use cases (like a document editor) it could be very useful for some people. again, these are apple UI _guidelines_ not words from god you must obey. allan stated below that he will be re-working things for 1.2, so i'll say no more on the topic and just wait for the changes to occur...
On 12/6/05, Charilaos Skiadas cskiadas@uchicago.edu wrote:
On Dec 6, 2005, at 2:38 PM, Jamal Johnson wrote:
i don't use the drawer. that's why i'm suggesting a simple CHECKBOX option. if you don't want it, don't check it. and if it drives you nuts NOT to have it, then click it....
My understanding is that the "multiple rows of tabs" design is a design that is pretty strongly discouraged by the Apple UI guidelines, and certainly not implemented by the system, and not easy to implement by hand either. So before we continue this discussion, please offer us some examples of other applications that do it this way.
What might be more productive is if we each describe how we use the project window, what *particular* operations we want to perform, and why we think a particular pattern would be best. I personally always use the "GoTo File" browser, and never even look at the tabs, unless I work with two particular files, in which case I'd place them next to each other and use option-command arrow keys. So I find no need to have a long list of all the files I have opened, taking up valuable space.
Yes, we *could* have a checkbox to make it an option, provided Allan implements what is a non-trivial construction, but we could do the same with 1500 other options, resulting in a completely chaotic and useless preferences menu. So if you want such an option, you need to make a *very* good usability argument.
Haris
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
i've used both windows and linux machines for a long time, before switching to a mac a year and a half ago, and they both offer multiple lines of rows in most cases.
windows isn't my idea of "user-friendly" or "elegant" interface, and the same goes for KDE (which is like windows-on-steroids). gnome might be a little more elegant -- to the point of being austere.
for text document like applications i definitely don't think it's a bad design decision for the use case of being able to see ALL my documents that i have open with a quick glance.
multiple rows of tabs aren't the way. having more than one row of them simply destroys the metaphore, having the rows move according to which item is selected destroys consistence, and (last but not least) it severely impedes keyboardability.
again, these are apple UI _guidelines_ not words from god you must obey.
1. steve jobs is god -- at least, don't tell him he's not, he might be upset ;) 2. note how programs that follow the spirit of the guidelines (give or take a pixel) end up feeling native and integrated to the system. the current tab appearence is _not_ the one prescribed by the HIG, yet they hold to the spirit. two rows of tabs break the spirit of the rules themselves (predictability, consistence, keyboardability to name a few). -1 all the way for me.
allan stated below that he will be re-working things for 1.2, so i'll say no more on the topic and just wait for the changes to occur...
I'm pretty sure allan will do the Right Thing, whatever it is… and I think he's already got some ideas, he just doesn't want to disclose them ;)
ciao,
Domenico
I would be happy provided that the currently open file has it's tab visible (currently, if it's to the right of the '>>' you can't see it). This IMHO breaks the metaphor, because the currently open file should be the topmost tab if you had them in a pile on your desktop
If there are too many open tabs, just put scrolling controls so the tabs can be moved right and left. IE, put '>' and '<' buttons to the right and left of the tabs to see more of them by scrolling them laterally.
Cheers, Victor
-- Victor Jalencas Victor.Jalencas@gmail.com
On 07.12.2005, at 16:43, Jamal Johnson wrote:
i understand that the apple ui guidlines discourage this kind of paradigm and being an interface engineer myself, in most cases i agree that if you have to have multiple rows of tabs you should try to organize your information in a more efficient way. but these are _guidlines_, not laws to follow. for instance a preference pane should not have multiple rows of tabs (which are the examples of windows apps most people have used as bad design decisions). i've used both windows and linux machines for a long time, before switching to a mac a year and a half ago, and they both offer multiple lines of rows in most cases. but i don't think that just because it's evil microsoft and apple says it's a "bad way to do it" that it's true in all use cases. for text document like applications i definitely don't think it's a bad design decision for the use case of being able to see ALL my documents that i have open with a quick glance. i work on many files in parrallel all the time, and leave files open i know i have things to do in. i'm a neurotic user of Cmd-T to open files, but if the file is already open i'd like to see that it is and not have to jump thru the hoops of opening the "find file" dialog, typing the name of the file and choosing it. it's simply much faster / easier to glance at the tabs and click the one i want, imho.
To maximize the amount of open files you can see at a glance, it is IMHO much better to put the files not in a horizontal list (tabs, see max. 15 files), but in a vertical list (see ~40 files). Of course you can't have vertical tabs, as this probably comes right after having multiple lines of tabs, design-wise.
But wouldn't it be cool to have the very list that Cmd-T gives you in the drawer? So you can switch the drawer between project view and open files view, or maybe have 2 drawers (with the possibility to see them both?). Cmd-T would focus the open files drawer (if its visible, otherwise bring up this small window) and work as it does now. But instead of it disappearing, you could have this list open all time. It would be sorted by name, and if you focus it by pressing Cmd-T, it would be sorted as a history (current behaviour). Is this worth thinking about, Allan?
Jonas
Fow what it's worth (not much, likely), I'm a definite -1 on multi-row tabs. The typical MS-style implementation is a UI horror show, as someone alluded to earlier.
-2 counting me…
(And as long as I've suggested that I'll slip in the suggestion that the drawer items could visually indicate saved/unsaved file state, too -- that's done in many other apps and is quite handy.)
that's already done if you're doing a "Find in Project…" — the icons are gray instead of white… I second your idea, paul. *and* I'd like to be able to tell somehow if there are modified files in a folder.
*and* I'd like filetype icons in the drawer too… :)
ciao,
Domenico
On 06 Dec 2005, at 15:45, Jamal Johnson wrote:
i'm sure there's been discussion of this before, but was wondering if there was anyway to add a preference to have the tabs for the open files of a project wrap to multiple lines instead of limiting them to one line and having that dropdown menu on the right show up. i like to see ALL the files i have open at once and can't stand that dropdown. is this possible? it seems the 'tab component' should be able to handle this. i can look into it if you'd like...
Please, not the multi-rows tabs again.
Search the list for previous threads about it or google for "rows of tabs shame".
Allan will re-work the project drawer and tabs, so we should wait for that first.
But anyway, I'm pretty confident Allan won't implement such a nightmare.
-- Fred
So if multirow tabs are such Bad Thing, maybe TM could at least make sure that most used tabs are always visible?
If file is opened, and there is no room for more tabs, TM could hide least recently used tab(s) to make more room, instead of opening file with invisible tab.
How about a shortcut that would at least reveal the menu of hidden tabs and allow for scrolling through it to select the desired file?
On 7/12/2005, at 12:23, Richard Sandilands wrote:
How about a shortcut that would at least reveal the menu of hidden tabs and allow for scrolling through it to select the desired file?
Try cmd-T, it sorts the files based on last-recently-used w/o a filter string.
As Fred said, I will rework the tabs and project drawer (in 1.2) and there are hundreds of posts about tabs on this ML, so I think the topic has been exhausted, at least until I actually start to role out changes to the existing system!
-
Allan Odgaard -
Charilaos Skiadas -
Domenico Carbotta -
Fred B. -
Horst Gutmann -
Jamal Johnson -
Jonas Witt -
Paul Bissex -
porneL -
Richard Sandilands -
victor jalencas