New KTabWidget

[Jason Keirstead]

On March 1, 2003 10:09 pm, Zack Rusin wrote:
> OK, well I did what I could while keeping it BC. So:
> a) The looks :
> http://www.cse.psu.edu/~mrusin/tabs.png
> http://www.cse.psu.edu/~mrusin/tabs1.png

Excellent look, much better than the buttons

> b) Fixes:
> a) the buttons (go figure), the actions for both (the left and the
> right) are customizable, so are the icons on them and one can hide one
> of both of them. The default is to hide them both to be consistent with
> older apps.

Excellent

> b) label coloring (that actually is not anything special and can be
> removed if it bothers anyone as it can be done in QTabBar derived
> classes)

Yes!

I would much like to use this widget in Kopete. Currently we have our own label
color change methods, but if this was in QT or kdelibs it would be much nicer.

I see you added these signals in QTabWidget:
	+    void rightButtonClicked();
	+    void leftButtonClicked();

Shouldnt you pass the QWidget pointer of the tab you clicked on with these? (like, if you
right click on the third tab, pass the pointer for that widget), Or at least the tab index? Any
slots using these signals are usually going to need the tab they were fired on... see Konq
code for example.

Also, it would be nice to emit a signal for contextMenuEvent for popup menus to use instead of
rightButtonClicked in case someone reversed their mouse buttons because they're a lefty.

Not sure if you addressed this issue, but here is another bug we came across
with QTabBar.. if you change the icon of a tab that is not currently visible
( a tab which is scrolled off to the left or right), it causes the tab to be scrolled
back into view, weather you wanted it to or not. This makes doing things like
blinking the tab icon for notifications impossible.

-- 
Jason Keirstead, BCS
http://www.keirstead.org