Tab bar in Files - why a new widget?

[Thomas Pfeiffer]

On 13.11.2012 12:10, Marco Martin wrote:
> On Tuesday 13 November 2012, Aaron J. Seigo wrote:
>> On Monday, November 12, 2012 15:12:01 Thomas Pfeiffer wrote:
>>> 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
>>
>> no separation is a slightly difficult problem (from a technical pov) given
>> how components are currently used; the background difference was sth i
>> also noted, but we don't currently have appropriate artwork available,
>> though we know it is sth we need.

I'm not even sure if we need a textured background for the drawer. Maybe just 
creating the impression of it being "below" the main window with shadows is 
already sufficient to separate them visually. In that case, it could have the 
same plain background as the tab buttons, as long as they look like they are on 
the same "level" (same position on the Z axis).

Btw: At least on my Wetab, there is currently a quite visible graphical glitch 
in the upper-left corner of the leftmost tab when it is active.

>> so 2 valid points, 1 we can fix with some art, and the other being less
>> easy.
>
> to add on it, i think is a problem not fully solvable in a satisfactory way:
> just taking a look at the qwidget side, even tough we all agree qtabbars are
> far from perfects, it amounts on the thousands of lines of c++ code, plus
> roughly another thousand in the oxygen style just to handle tabbar
> cornercases. (and yet it still doesn't work everywhere)
>
> tabbars are one of the most extraordinarly complicated problems in writing a
> component set, so in the end the decision of the standard component not trying
> to connect with a frame in any way was also in part to keep things sane.
> (and as a counter effect it may require from time to time a custom
> implementation)

Hm, sounds really... nasty. Well, I can only say how it would ideally be be from 
a UX POV, but of course we can only work with what is technically feasible.