Some QTabBar & QTabWidget love

Published Wednesday July 2nd, 2008
9 Comments on Some QTabBar & QTabWidget love
Posted in Qt

After 4.4.0 was out I set aside some time to go though the feature requests for QTabBar & QTabWidget. After making a list of the most voted for suggestions I have implemented some features that will be in 4.5.0 that should make some developers happy.

In the past ten years the tab widget has gone from being something you see in a settings dialog to the widget that is the central widget of QMainWindow for many applications. Trying to use QTabWidget in the main window as it is in 4.4.0 has a number of shortcomings. One big issue is that if you maximize your application and move your mouse to the far right and try to scroll it wont because the mouse is actually over the 2px frame and not the scrollbar. I present for your enjoyment QTabWidget::documentMode which will only put the frame on the top with the tabs. Another very annoying problem for QTabWidget was that if you wanted to add a context menu or handle any event in the tab bar area you had to subclass both QTabBar and QTabWidget because the empty area was actually owned by QTabWidget and the tab bar widget was only as big as the tabs. Document mode will cause the tab bar widget to take up the entire space above the tab widget which will simplify a lot of code.

Looking around at what features people have implemented in their subclasses of QTabBar many have added some sort of hack to be able to either put a widget on a tab or the ability to paint a button. Doing this right, QTabBar now has a function QTabBar::setTabButton to let you put a widget on the left or right hand side of each tab. Taking this one step further there is also a convenience property
QTabBar::tabsClosable that when enabled will automatically add a close button to each tab. The close button it painted by the style using PE_IndicatorTabClose. When the close button is pressed the signal tabCloseRequested is emitted. Note that the location of the close button is also determined by the style so you can not guarantee that it will always be on the right hand side and the side with the close button should be determined by a call to the style with SH_TabBar_CloseButtonPosition. Custom styles that paint tabs themselves needs to be updated to take into account the space needed for buttons (see QStyleOptionTabV3).

When a tab is closed rather then always selecting the tab to the right there is now a
QTabBar::selectionBehaviorOnRemove property to decide which tab should be selected. The three included values are left, right and the last selected tab.

Another highly requested feature is support for the ability to move tabs. There is even a number of patches floating around out there that add many different moving schemes. A moveTab function was added, but taking it to the next level the property movable has been added which lets you drag the tabs around and as you pass over tabs they slide to their new position (i.e. animated sexiness).

Because animations are hard to describe I made a short video. In the video I first add a QTabWidget to a QMainWindow, turn on document mode, closeable tabs, and the moveable property. Then I preview it in plastique and drag around a few tabs. I start out using cleanlooks so it picks up the Gtk close button and then in plastique you can see it using the default button.

Lastly for applications running in OS X when using document mode the style paints the entire tab bar to match those tabbed applications like Safari and Terminal that are found on OS X. Below is a screenshots of a QTabWidget in a QMainWindow with a QWebView. With OS X it is very clear that the tab widget now goes to the edge of the screen.

osxstyletabbar.png

Hope you all enjoy it. Some of the patches are already in Qt main, but you can find all of these in tonight’s snapshots. Let me know if you notice any issues with the new features.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Qt

9 comments

xxx says:

If only you could cut on the disinformation… “This makes Qt the only toolkit where you can get this tab style and this includes Carbon and Cocoa”?! Yeah, sure, maybe in your dreams: http://www.positivespinmedia.com/dev/PSMTabBarControl.html

ariya says:

Now Arora (on Mac OS X) with the new style and movable tabs is not distinguishable from Safari πŸ™‚

Mike Krus says:

nice one!

one thing we’ve implemented is detachable tabs, a little like Microsoft’s. Simply drag a tab widget and it gets removed from the tab set, and converted into a dock widget for the parent main window. Close the dock window and it pops back in as a tab in the original tab set…

Could be nicer with drag effects but it works otherwise as expected.

One thing concerning tab widgets I’d like to have is easy access to the QTabBars of docked widgets, so I can more easily add icons to them. Or change the default QMainWindow to pickup the window icons of docked widgets and use them on the tabs…

Mike

Benjamin Meyer says:

@Mike When implementing the moving I tried out the code on some other applications that hnd implemented their own dnd to make sure that it wouldn’t interfere. I even played around and made sure I could combine the movable with a simple dnd that can pull the tab off the bar. At the bare minimum you can always just not enable the movable and you still get all of the rest of the new features. πŸ™‚ On the dock widgets, while scanning through the tasks I did see a suggestion to be able to get access to the tabbar so you are not the only one that wants that feature and it is on the dock team’s list.

qtuser says:

The OSX version looks absolutely amazing!

Great work!

And the moving tabs back into place is just fantastic.

Will the new tab widget respect:: setUnifiedTitleAndToolBarOnMac(true) ??

I use it to great effect and it should show the toolbar above then the tabs in the pic above.

Konstantin says:

hi, Benjamin. I hear U wrote this features in about three weeks…good job!

I spectate for tabbar-tabwidget changes on 4.5.0 trunk, I tested well every new feature and finally I have several suggestions…here they are:

> QTabBar::tabsClosable that when enabled will automatically add a close button to each tab.
* it would be nicer if we can choose where to show close button(s):
1) on each tab;
2) on active tab only;
3) on each tab if (tab’s width > closeButton’s width * 2) else on active tab only /* like in Opera */

* it would be usefull to have something like QTabBar::ButtonPosition QTabBar::defaultCloseButtonPosition() const (wrapper for style()->styleHint(QStyle::SH_TabBar_CloseButtonPosition, 0, this))

* moveTab method must be public (optionally slot)!

* tab moving using mouse must not be limited by first and last [b]visible[/b] tabs – this behavior makes manual tab moving unusable when usesScrollButtons == true and we have much more tabs than our screen can contains. I mean tabBar must to scroll tabs left or right when dragged tab goes closer to first or last visible tab.

regards

Giorgio says:

what about skype-style multiple row tabbar ?

regards

Benjamin Meyer says:

@xxx: Sorry I didn’t know about PSMTabBarControl, I have removed that comment from the blog.

@qtuser: Yup, it works great with setUnifiedTitleAndToolBarOnMac. I have put a screenshot of it in Arora which has setUnifiedTitleAndToolBarOnMac enabled up here that you can checkout: http://arorabrowser.blogspot.com/2008/07/better-tab-bar.html

@giorgio, there is an open suggestion for multiple rows and it currently just has 1 vote (non critical). I tried to implement the features that would benifit the most number of users.

@Konstantin: yah the moveTab should be public to go with the add/remove functions which are also public. I ran it by another troll first for API review and submitted the change. As for the other three I will have to do a little more investigation.

Freddie says:

I like it. Will try it later on today (OS X).

@giorgio: I am not so sure there. Multiple tab rows is a very Windows concept which never seemed to catch-on elsewhere. (Although OpenOffice.org does make use of them, resulting in some strange looking interfaces when the Qt/GTK styles are used.) Normally if I find myself needing so many tabs that a second row seems attractive I reconsider my UI/layout (not normally a good idea to have that many, at least that is what I have found).

Detachable tabs, ala Safari, would be neat — both visually and practically.

Commenting closed.

Get started today with Qt Download now