Tab bar in Files - why a new widget?

[Marco Martin]

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.
> 
> 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)

Cheers, 
Marco Martin