KTabBar - suggestion for 4.1

[Robert Knight]

Hi Olivier,

> But the style should (in an ideal world) choose the
> presentation of it, i.e
>  2. hover close button with no delay
> | 3. hover close button with delay
> | 4. close button on the right
> | (5. Middle button click.)
> 

Those are differences in behaviour as well as presentation.  In the case
of 'middle click' I have had several different conflicting bug reports
asking for different things to happen when people middle click on tabs.
It would be simpler for me just to have one behaviour that I can rely on
and document in the handbook accordingly.

Regards,
Robert.

On Thu, 2008-04-17 at 00:25 +0200, Olivier Goffart wrote:
> Le mercredi 16 avril 2008, Andras Mantia a écrit :
> > On Thursday 17 April 2008, Olivier Goffart wrote:
> > > But the application should NOT be able to choose between different
> > > behaviour. It's importent that the behaviour is the same in each
> > > every KDE Application. I see no reason to have different behaviour in
> > > Konqueror, Kopete, Kate, ....
> >
> > While I agree with this statement, 
> 
> Fine... :-)
> 
> 
> 
> 
> > that is nothing to do with the style. 
> > A style is just a visual presentation of the widgets. So if the
> > decision is to have a close button on the tabs, then this decision
> > should be honored by the style. How that close button is drawn, can be
> > changed, but not the fact that the close button appears or not.
> > I hope it's clear now what I meant.
> 
> Yes, the fact that the close button appears on the tab should not be choosed 
> by the style. 
> But the style should (in an ideal world) choose the presentation of it, i.e
> 
> | 2. hover close button with no delay
> | 3. hover close button with delay
> | 4. close button on the right
> | (5. Middle button click.)
> 
> For example, look how the style control the behaviour of a QComboBox,  look 
> the popup in plastique, and the popup cleanlooks.
> (In plastique it has a scrollbar, and in cleanlooks it has up and down buttons 
> like in macOs)