[TxMt] multi-row tabs

Jamal Johnson jamal.johnson at gmail.com
Wed Dec 7 15:43:32 UTC 2005


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 at 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 at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
> http://lists.macromates.com/mailman/listinfo/textmate
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20051207/2aa2ccec/attachment.html>


More information about the textmate mailing list