That's true. I always have to open a new shell to test out a command because I don't want to lose my place in the man pages I was viewing to find out what the command is.
But that is why CLI lost to GUI - everything scrolls off and you have to keep listing things over and over to be able to keep them in reach.
Quote:
Originally posted by iDunno
And that is all I have to say about that. Safari has them, how hard can it be to put it in Terminal... and Finder as well.
I'd like to see Terminal.app get tabs as well. What a great terminal software! As an ex-linux user, I really appreciate the a) eyecandy transparent terms and b) conventional, good old copy and paste into and out of Terminal.
Tabs are good. I mean if you don't like 'em don't use 'em. Finder and iChat, hell even Mail, maybe even more apps like Calendar, could use them. Why? I have a 12" screen. OS X likes screen. Tabs are a solution. The end.
I'd like to see Terminal.app get tabs as well. What a great terminal software! As an ex-linux user, I really appreciate the a) eyecandy transparent terms and b) conventional, good old copy and paste into and out of Terminal.
Agreed. One thing I disliked about working with the terminal in Suse was that I couldn't cut, copy and paste in it ... just the old line by line cut. Extremely annoying when trying to copy in code, etc. But then again, I loved the tabbed terminal. I could compile and run in one tab while I wrote code on the other.
Tabbed finder I could really care less about ... the icons on the left sort of act like tabs anyway ... but tabbed terminal ... yes ... TAKE HEED APPLE!!!!
Tabs are good. I mean if you don't like 'em don't use 'em. Finder and iChat, hell even Mail, maybe even more apps like Calendar, could use them. Why? I have a 12" screen. OS X likes screen. Tabs are a solution. The end.
Expose is a solution. So is buying a larger monitor.
Tabs are good for very specific situations (similarly sized windows of similar *static* content), and a nightmare anywhere else. They also, if you stop and think about it, cancel out most of the ability to drag and drop between windows... which is idiotic.
Finder has the right size constraints, but the usefulness for drag and drop means that straight tabs would gut the app. You'd have to have tabs that accept hover-drops by coming to the fore, like folders in Column View. Not that hard, but a detail to consider.
iChat? Right size constraints (usually), but I generally have multiple chats going at once, and like to see the progress in each at a glance without having to switch back and forth. Perhaps if you felt the need to keep a bunch of dead chats open, although why you'd want to do that is beyond me. *shrug* I want them visible when active, and closed when dead. Tabs don't offer any benefit.
Mail? Okay... decent size constraint adherence, but you've got two types of mail messages: incoming (static content) and outgoing (dynamic content). For incoming, you already *have* what is essentially a tabbed windowing system. Think about it - you have a list of msgs, and you click on one at a time to view them. That's a tabbed interface, without the tabs. For outgoing, I don't see how making the composition window tabbed is going to help anything. How many outgoing msgs are you composing at one time? For myself, that number is never over 3 or 4, and if it's over 2, I tend to use Drafts to get back to them later. I can't imagine a workflow scenario where I'd need umpteen composition windows open, and some way of managing just those.
iCal? Er... why/how? Seriously, I really don't see any way that tabs are going to help a single-window app. I think you've gone bonkers on this one, unless you have an all new UI in mind.
Tabs were created to try and get around the piss-poor window management schemes in other systems. MacOS X doesn't have the original problems, so doesn't need the system-wide solution. Tabs are good *in specific instances*. A browser, for example, where the content is static, the assumed size of window is more or less constant, and user interaction is based on consumption, not creation. Otherwise, they just add a level of UI complexity that *IS* a problem to work around.
I simply don't understand the tab fetish. I use them in Safari, but I haven't found another situation where they are actually useful. I *thought* they'd be useful in the Terminal, but they never were. I have too many situations where I need to keep an eye on one process while working on another. Tabs don't let me do that. For quick one-off needs of a new shell, Cmd-N, do-task, Cmd-W always works, as does just invoking a new shell within an existing Terminal window. That's the fastest, really.
So no, really, please... don't throw tabs in willy-nilly. They just screw up more than they add. And no, "then don't use them" is not a viable counter-argument... that way leads to Linux UIs.
Exposé is sorta a substitute. Buying a monitor...I have a laptop. A small one. For a reason. And as for drag n drop, they should simply implement it where if you drag something out of one tab, and on to another, it selects it, in other words, opens it, switches to its view, etc. You know what I mean? Sort of like how you can drag n drop with Exposé. Simple. Makes sense. Tabs ARE a kludge, but just like Exposé or SringLoaded Folders. They're for people with small monitors, plain and simple. Not everyone can have a 30" Cinema Display. It's that simple. They should be an option that's off by default.
Aquatic, I hate to break it to you, but it's clear Apple has left behind the owners of 1024x768 screens. And I say that as someone who only recently moved from that very resolution.
Just think of all the new obscenely wide apple.com pages. They barely even fit on a 1280x800 screen, but 1024x768? No dice.
Exposé is sorta a substitute. Buying a monitor...I have a laptop. A small one. For a reason. And as for drag n drop, they should simply implement it where if you drag something out of one tab, and on to another, it selects it, in other words, opens it, switches to its view, etc. You know what I mean? Sort of like how you can drag n drop with Exposé. Simple. Makes sense.
I agree - *if* you're going to use tabs, then you absolutely positively have to make them active drop-triggers, ala Column View folders or Expose windows. Anything less is just horrific. And yes, that takes care of some of the problem with tabs... but not all.
Quote:
Tabs ARE a kludge, but just like Exposé or SringLoaded Folders.
Eh, I disagree on that point. Exposé is a UI element that is 100% orthogonal to everything else, and works with any window on the system. That is *powerful*, and the proper way to introduce new tools for UI workflow. Tabs, OTOH, take a standard UI element, the window, and... mutate it. Now you have to decide what Cmd-W does in the presence of tabs (whoops, inconsistency), how to handle drop sites, whether they should be movable or static, what types of windows should be tabbable, etc, etc, etc. Basically you have to rethink a lot of the very nature of windows in general, just to integrate them. To me, that's a kludge. You're stepping on the toes of a basic window to try and get around a problem that isn't there to begin with.
IMO, Exposé, App hiding, and Window minimizing are a much more powerful set of tools for window navigation and selection than tabs ever could be. Simple, orthogonal, specialized tools that work in an interlocking manner without getting in each others' way. Brilliant.
Quote:
They're for people with small monitors, plain and simple. Not everyone can have a 30" Cinema Display. It's that simple.
So you're willing to give up a precious 32px or so of height all the time then for the tabs, when you have other ways of dealing with the problem already provided? Can I just say I find that weird?
Quote:
They should be an option that's off by default.
For *very specific apps*, sure. For a system-wide UI element? F*ck no. Otherwise you're going to see even more of what we have now - tabbois screaming for tabs everywhere, because they're k3wl, and gosh darnit, it's what they're used to in other UIs... when they're shooting themselves in the foot by not learning a more efficient workflow. Normally I'd say "Let 'em", but when you're talking about a system-wide UI element, it shoots *everyone* in the foot when devs start throwing it around like confetti.
OTOH, having an NSTabbedWindow from Apple might unify some of the various approaches we've seen come out of shareware apps that have been half-baked. The problem is, they'd have to come with some very specific and detailed HIG rules. For the devs to ignore, of course. :P
Count Terminal.app among them (with "user friendly" tabs, ie. sensitive to pointing with an item to drop, keyboard-navigable and detachable, like in Linux). And perhaps no other application for the moment.
Count Terminal.app among them (with "user friendly" tabs, ie. sensitive to pointing with an item to drop, keyboard-navigable and detachable, like in Linux).
Which shell application from which windowing manager? (Sorry, personal nit to pick - Linux is the underlying layers. When you want to talk about GUI apps or elements on Linux, you have to be precise as to which windowing system you're talking about.)
Quote:
And perhaps no other application for the moment.
And yet I still don't see the need for them even there. Maybe I just don't understand the workflow that leads to such a need... educate me? Like I said above, most of the time I am needing to keep an eye on multiple windows at once while I edit in one, compile in another, run regression tests in a third, etc, etc. I can't do that with tabbed windows. The only time I can see it working with my own workflow is that I have two windows that are dedicated to SVN and CVS control (for the same directories - two repositories - very funky, don't ask) and I have to make very sure that I keep them distinct and straight. I'm only ever working with one at a time, so there I can see a tab working. The rest of the time though it would just get in the way. *shrug*
Which shell application from which windowing manager? (Sorry, personal nit to pick - Linux is the underlying layers. When you want to talk about GUI apps or elements on Linux, you have to be precise as to which windowing system you're talking about.)
Konsole, KDE.
Quote:
And yet I still don't see the need for them even there. Maybe I just don't understand the workflow that leads to such a need... educate me?
When you have some hundreds or thousands of files in a directory, and you need to execute some commands inside this directory while keeping an eye on the files through the shell (listing, content etc.), I find it extremely handy to have navigable tabs. Even more so if at the same time you have interaction with other directories.
If you cannot navigate through the tabs with the keyboard, the added value is minimal or zero (unless you are in a small sized display).
When you have some hundreds or thousands of files in a directory, and you need to execute some commands inside this directory while keeping an eye on the files through the shell (listing, content etc.), I find it extremely handy to have navigable tabs. Even more so if at the same time you have interaction with other directories.
Now I'm even more confused. How do you keep an eye on the files at the same time as working on them, with tabs? What do tabs get you *over* using plain windows? With two windows, I can put one on one side, filtering, and the other on the other side of the screen, where I'm working and see the results in real-time by just glancing over. Or, if I don't have the screenspace to spare, flip between the two with Cmd-`, or, I can glance up and see the Cmd-<number> keystroke that will take me right to the window I want.
Quote:
If you cannot navigate through the tabs with the keyboard, the added value is minimal or zero (unless you are in a small sized display).
So Cmd-Shift-RightArrow is better than Cmd-`? I'm not trying to be obstinate, I'm genuinely confused as to the benefits that outweigh the issues that tabs raise with UI in general.
Now I'm even more confused. How do you keep an eye on the files at the same time as working on them, with tabs? What do tabs get you *over* using plain windows? With two windows, I can put one on one side, filtering, and the other on the other side of the screen, where I'm working and see the results in real-time by just glancing over.
In my case it is often much more than two windows and tabs make inspection easy, since all are in the front (well, overlapped) and you can switch between them very quickly.
In my case it is often much more than two windows and tabs make inspection easy, since all are in the front (well, overlapped) and you can switch between them very quickly.
Alright, I can see where if you had just two out of a plethora of windows that you wanted to toggle between, that having the ability to cycle within that subgroup would be handy.
It would seem, however, that a toggle-to-last behaviour with Cmd-`, as we have with Cmd-Tab would be similar, and a lot less invasive of the current UI.
Quote:
It would be Cmd-RightArrow or Shift-RightArrow.
*shrug* The specific keystrokes were unimportant, I was interested in what the necessary distinction in behaviour was. The point stands, and you made the case.
I don't think it does, because it sounds like what IE users would tell first Opera, then Firefox, and then Safari users when faced with a conversation about tabs.
"It's better this way!"
It is not. Luckily there are alternatives, and they are far better than Terminal.
Regardless of Apple's eventual decision to include Tabbed Browsing in Safari 1.0, and regardless to the fact that I use Tabbed Browsing myself as well, I'm still opposed to them. I want better window management.
Comments
But that is why CLI lost to GUI - everything scrolls off and you have to keep listing things over and over to be able to keep them in reach.
Originally posted by iDunno
And that is all I have to say about that. Safari has them, how hard can it be to put it in Terminal... and Finder as well.
Originally posted by 1337_5L4Xx0R
I'd like to see Terminal.app get tabs as well. What a great terminal software! As an ex-linux user, I really appreciate the a) eyecandy transparent terms and b) conventional, good old copy and paste into and out of Terminal.
Agreed. One thing I disliked about working with the terminal in Suse was that I couldn't cut, copy and paste in it ... just the old line by line cut. Extremely annoying when trying to copy in code, etc. But then again, I loved the tabbed terminal. I could compile and run in one tab while I wrote code on the other.
Tabbed finder I could really care less about ... the icons on the left sort of act like tabs anyway ... but tabbed terminal ... yes ... TAKE HEED APPLE!!!!
EDIT: Tabs in iChat would rock also...
Originally posted by Aquatic
Tabs are good. I mean if you don't like 'em don't use 'em. Finder and iChat, hell even Mail, maybe even more apps like Calendar, could use them. Why? I have a 12" screen. OS X likes screen. Tabs are a solution. The end.
Expose is a solution. So is buying a larger monitor.
Tabs are good for very specific situations (similarly sized windows of similar *static* content), and a nightmare anywhere else. They also, if you stop and think about it, cancel out most of the ability to drag and drop between windows... which is idiotic.
Finder has the right size constraints, but the usefulness for drag and drop means that straight tabs would gut the app. You'd have to have tabs that accept hover-drops by coming to the fore, like folders in Column View. Not that hard, but a detail to consider.
iChat? Right size constraints (usually), but I generally have multiple chats going at once, and like to see the progress in each at a glance without having to switch back and forth. Perhaps if you felt the need to keep a bunch of dead chats open, although why you'd want to do that is beyond me. *shrug* I want them visible when active, and closed when dead. Tabs don't offer any benefit.
Mail? Okay... decent size constraint adherence, but you've got two types of mail messages: incoming (static content) and outgoing (dynamic content). For incoming, you already *have* what is essentially a tabbed windowing system. Think about it - you have a list of msgs, and you click on one at a time to view them. That's a tabbed interface, without the tabs. For outgoing, I don't see how making the composition window tabbed is going to help anything. How many outgoing msgs are you composing at one time? For myself, that number is never over 3 or 4, and if it's over 2, I tend to use Drafts to get back to them later. I can't imagine a workflow scenario where I'd need umpteen composition windows open, and some way of managing just those.
iCal? Er... why/how? Seriously, I really don't see any way that tabs are going to help a single-window app. I think you've gone bonkers on this one, unless you have an all new UI in mind.
Tabs were created to try and get around the piss-poor window management schemes in other systems. MacOS X doesn't have the original problems, so doesn't need the system-wide solution. Tabs are good *in specific instances*. A browser, for example, where the content is static, the assumed size of window is more or less constant, and user interaction is based on consumption, not creation. Otherwise, they just add a level of UI complexity that *IS* a problem to work around.
I simply don't understand the tab fetish. I use them in Safari, but I haven't found another situation where they are actually useful. I *thought* they'd be useful in the Terminal, but they never were. I have too many situations where I need to keep an eye on one process while working on another. Tabs don't let me do that. For quick one-off needs of a new shell, Cmd-N, do-task, Cmd-W always works, as does just invoking a new shell within an existing Terminal window. That's the fastest, really.
So no, really, please... don't throw tabs in willy-nilly. They just screw up more than they add. And no, "then don't use them" is not a viable counter-argument... that way leads to Linux UIs.
Just think of all the new obscenely wide apple.com pages. They barely even fit on a 1280x800 screen, but 1024x768? No dice.
Originally posted by Aquatic
Exposé is sorta a substitute. Buying a monitor...I have a laptop. A small one. For a reason. And as for drag n drop, they should simply implement it where if you drag something out of one tab, and on to another, it selects it, in other words, opens it, switches to its view, etc. You know what I mean? Sort of like how you can drag n drop with Exposé. Simple. Makes sense.
I agree - *if* you're going to use tabs, then you absolutely positively have to make them active drop-triggers, ala Column View folders or Expose windows. Anything less is just horrific. And yes, that takes care of some of the problem with tabs... but not all.
Tabs ARE a kludge, but just like Exposé or SringLoaded Folders.
Eh, I disagree on that point. Exposé is a UI element that is 100% orthogonal to everything else, and works with any window on the system. That is *powerful*, and the proper way to introduce new tools for UI workflow. Tabs, OTOH, take a standard UI element, the window, and... mutate it. Now you have to decide what Cmd-W does in the presence of tabs (whoops, inconsistency), how to handle drop sites, whether they should be movable or static, what types of windows should be tabbable, etc, etc, etc. Basically you have to rethink a lot of the very nature of windows in general, just to integrate them. To me, that's a kludge. You're stepping on the toes of a basic window to try and get around a problem that isn't there to begin with.
IMO, Exposé, App hiding, and Window minimizing are a much more powerful set of tools for window navigation and selection than tabs ever could be. Simple, orthogonal, specialized tools that work in an interlocking manner without getting in each others' way. Brilliant.
They're for people with small monitors, plain and simple. Not everyone can have a 30" Cinema Display. It's that simple.
So you're willing to give up a precious 32px or so of height all the time then for the tabs, when you have other ways of dealing with the problem already provided? Can I just say I find that weird?
They should be an option that's off by default.
For *very specific apps*, sure. For a system-wide UI element? F*ck no. Otherwise you're going to see even more of what we have now - tabbois screaming for tabs everywhere, because they're k3wl, and gosh darnit, it's what they're used to in other UIs... when they're shooting themselves in the foot by not learning a more efficient workflow. Normally I'd say "Let 'em", but when you're talking about a system-wide UI element, it shoots *everyone* in the foot when devs start throwing it around like confetti.
OTOH, having an NSTabbedWindow from Apple might unify some of the various approaches we've seen come out of shareware apps that have been half-baked. The problem is, they'd have to come with some very specific and detailed HIG rules. For the devs to ignore, of course. :P
Originally posted by Kickaha
For *very specific apps*, sure.
Count Terminal.app among them (with "user friendly" tabs, ie. sensitive to pointing with an item to drop, keyboard-navigable and detachable, like in Linux). And perhaps no other application for the moment.
Originally posted by PB
Count Terminal.app among them (with "user friendly" tabs, ie. sensitive to pointing with an item to drop, keyboard-navigable and detachable, like in Linux).
Which shell application from which windowing manager? (Sorry, personal nit to pick - Linux is the underlying layers. When you want to talk about GUI apps or elements on Linux, you have to be precise as to which windowing system you're talking about.)
And perhaps no other application for the moment.
And yet I still don't see the need for them even there. Maybe I just don't understand the workflow that leads to such a need... educate me? Like I said above, most of the time I am needing to keep an eye on multiple windows at once while I edit in one, compile in another, run regression tests in a third, etc, etc. I can't do that with tabbed windows. The only time I can see it working with my own workflow is that I have two windows that are dedicated to SVN and CVS control (for the same directories - two repositories - very funky, don't ask) and I have to make very sure that I keep them distinct and straight. I'm only ever working with one at a time, so there I can see a tab working. The rest of the time though it would just get in the way. *shrug*
So, what am I missing?
Originally posted by Kickaha
Which shell application from which windowing manager? (Sorry, personal nit to pick - Linux is the underlying layers. When you want to talk about GUI apps or elements on Linux, you have to be precise as to which windowing system you're talking about.)
Konsole, KDE.
And yet I still don't see the need for them even there. Maybe I just don't understand the workflow that leads to such a need... educate me?
When you have some hundreds or thousands of files in a directory, and you need to execute some commands inside this directory while keeping an eye on the files through the shell (listing, content etc.), I find it extremely handy to have navigable tabs. Even more so if at the same time you have interaction with other directories.
If you cannot navigate through the tabs with the keyboard, the added value is minimal or zero (unless you are in a small sized display).
Originally posted by PB
Konsole, KDE.
Thanks.
When you have some hundreds or thousands of files in a directory, and you need to execute some commands inside this directory while keeping an eye on the files through the shell (listing, content etc.), I find it extremely handy to have navigable tabs. Even more so if at the same time you have interaction with other directories.
Now I'm even more confused. How do you keep an eye on the files at the same time as working on them, with tabs? What do tabs get you *over* using plain windows? With two windows, I can put one on one side, filtering, and the other on the other side of the screen, where I'm working and see the results in real-time by just glancing over. Or, if I don't have the screenspace to spare, flip between the two with Cmd-`, or, I can glance up and see the Cmd-<number> keystroke that will take me right to the window I want.
If you cannot navigate through the tabs with the keyboard, the added value is minimal or zero (unless you are in a small sized display).
So Cmd-Shift-RightArrow is better than Cmd-`? I'm not trying to be obstinate, I'm genuinely confused as to the benefits that outweigh the issues that tabs raise with UI in general.
Originally posted by Kickaha
Now I'm even more confused. How do you keep an eye on the files at the same time as working on them, with tabs? What do tabs get you *over* using plain windows? With two windows, I can put one on one side, filtering, and the other on the other side of the screen, where I'm working and see the results in real-time by just glancing over.
In my case it is often much more than two windows and tabs make inspection easy, since all are in the front (well, overlapped) and you can switch between them very quickly.
So Cmd-Shift-RightArrow is better than Cmd-`?
It would be Cmd-RightArrow or Shift-RightArrow.
Originally posted by PB
It would be Cmd-RightArrow or Shift-RightArrow.
Those are taken.
Originally posted by PB
In my case it is often much more than two windows and tabs make inspection easy, since all are in the front (well, overlapped) and you can switch between them very quickly.
Alright, I can see where if you had just two out of a plethora of windows that you wanted to toggle between, that having the ability to cycle within that subgroup would be handy.
It would seem, however, that a toggle-to-last behaviour with Cmd-`, as we have with Cmd-Tab would be similar, and a lot less invasive of the current UI.
It would be Cmd-RightArrow or Shift-RightArrow.
*shrug* The specific keystrokes were unimportant, I was interested in what the necessary distinction in behaviour was. The point stands, and you made the case.
Originally posted by Kickaha
The point stands, and you made the case.
I don't think it does, because it sounds like what IE users would tell first Opera, then Firefox, and then Safari users when faced with a conversation about tabs.
"It's better this way!"
It is not. Luckily there are alternatives, and they are far better than Terminal.