Tab bar in Files - why a new widget?

[Thomas Pfeiffer]

On 12.11.2012 11:00, Aaron J. Seigo wrote:
> On Monday, November 12, 2012 10:09:45 Thomas Pfeiffer wrote:
>> It reduces consistency. If we don't like the other representation
>> too much, we should improve that one, but not introduce another
>> representation for the same function.
>
> it isn't actually a new component, it's the button group component. however,
> it is being used as a stacked content switcher / tab bar in this context.
>
> why:
>
> * it benefits from a strong visual attachment cue between it and the content
> below, due to other elements in the window being possible association targets.

At least in the version currently in Master, there is a (thin) border between 
the "active tab" and the content, and the tab buttons are visually more similar 
to the toolbar (grey gradient) than to the content (weaving pattern). This is 
not the visual attachment I expect from what I learned about tab bars, which is
- No separation between active tab and content
- Active tab has the same background as the content

> * keeping it in the toolbar gives more room for the content being shown while
> also increasing opportunities for visual alignment within the window.

Sure, the placement totally makes sense.

> the existing toolbar component does not lend itself well to this kind of usage
> as it is a "floating" tab bar representation. in the "add to activity" page,
> there is only the paged content and there is no horizontal division between
> the content below and the tab bar above on which anchor a button group as in
> Files.
> the same is true in active-documentviewer: no competing content, no strong
> visual anchor points.

Okay, I get the alignment problem.

> how to harmonize these usages is a good question.

Yes. I don't think "Choose the one that looks better" works for a general UI 
pattern / HIG. I guess we'll have to look into that in more detail.