Bug 207747 - KTabWidget::setTabCloseActivatePrevious doesn't get along with QTabBar::setSelectionBehaviorOnRemove (Qt 4.5)
Summary: KTabWidget::setTabCloseActivatePrevious doesn't get along with QTabBar::setSe...
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: kdeui (show other bugs)
Version: 4.3.1
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2009-09-18 02:09 UTC by Eike Hein
Modified: 2009-11-14 02:30 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eike Hein 2009-09-18 02:09:47 UTC
KTabWidget has a setTabCloseActivatePrevious(bool). In Qt 4.5, QTabBar got a new setSelectionBehaviorOnRemove(SelectionBehavior) that can be used to achieve the same behavior. Unfortunately, the two don't get along well.

When you set setTabCloseActivatePrevious(true) on your KTabWidget, it doesn't take care to set setSelectionBehaviorOnRemove(QTabBar::SelectPreviousTab) on its KTabBar instance (a QTabBar subclass). Because QTabBar's default is QTabBar::SelectRightTab, that means that when a tab is closed, QTabWidget/QTabBar will first activate an adjacent tab before KTabWidget/KTabBar activates the previously active tab.

This caused a significant data loss bug in Konversation, which colorizes tab labels to signal activity in tabs, and resets the label color to the normal system color scheme color when a tab is activated. The brief (to the point where it's invisible, i.e. the user doesn't realize it happened) activation of a tab and then another means that the activity info on the tab first switched to is lost to the user.

I worked around this in SVN revision 1025089 by introducing a KTabWidget subclass to make QTabWidget::tabBar(), which is normally a protected function, public, so I could call setSelectionBehaviorOnRemove() on the tab bar when Konversation is built against Qt 4.5 or higher. See: http://websvn.kde.org/?view=rev&revision=1025089

However, this obviously needs to be fixed in kdelibs.
Comment 1 Eike Hein 2009-09-18 02:57:23 UTC
(Please note that I object against changing the severity of this bug to "Normal" on account of this being a data loss bug likely in other application as well and the documentation of the "Severity" field defining data loss bugs as "critical".)
Comment 2 Dario Andres 2009-09-19 21:56:51 UTC
Some time ago we discussed about this to move KTabWidget to use this new QTabBar option (and remove some code duplication). Check the full discussion on bug 181124 (isn't it related to this too?)
Thanks
Comment 3 Dario Andres 2009-10-11 17:24:05 UTC
Patch proposed at http://reviewboard.kde.org/r/1823/ . Regards
Comment 4 Dario Andres 2009-11-14 02:30:55 UTC
SVN commit 1048848 by darioandres:

- Update KTabBar and KTabWidget to use the Qt "setSelectionBehaviorOnRemove" implementation
  - Implements http://reviewboard.kde.org/r/1823/

BUG: 181124
BUG: 207747


 M  +2 -4      ktabbar.cpp  
 M  +3 -21     ktabwidget.cpp  
 M  +4 -1      ktabwidget.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1048848