Thanks for the bug report! I can confirm the bug in KTabWidget, seems to be a regression caused by

http://websvn.kde.org/?view=revision&revision=1011036

> (On a sidenote: Imho the left mouse button should be used for moving tabs
> around, to remain consistent with the rest of KDE (Dolphin, Konsole, etc.).
> I'll open up another bugreport about this later)

It seems that Darío did just that recently:

http://websvn.kde.org:80/?view=revision&revision=1048866

Personally I also think it's a nice idea, but some people might miss the possibility to drag the URL from a tab now and drop it somewhere else (before that commit, you could do that with the left mouse button, and moving was done using the middle mouse button).

Was that behaviour change intentional, Darío?

No, it wasn't intentional. 

The KTabWidget API states:

     * @deprecated Use QTabWidget::setMovable() instead.
     */
    QT_MOC_COMPAT void setTabReorderingEnabled( bool enable );

However, it seems that KTabBar is still using its own implementation of movable tabs... So using the "QTabWidget::setMovable()" method will conflict with this. (causing undesired behavior).

A big sigh... I guess the KTabBar code should be updated to reuse the QTabBar/QTabWidget code/behavior......

I guess the code could be reverted until we implement this on KTabBar......

SVN commit 1050732 by darioandres:

- Revert the use of QTabWidget::setMovable as it seems the API is not ready to replace the old
  KTabWidget::setTabReorderingEnabled()

CCBUG: 214646


 M  +1 -1      konqtabs.cpp  


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

I'll CC Michael who committed the change that caused this regression.

Michael: It seems that the signals tabMoved(int, int) of QTabBar and moveTab(int, int) of KTabBar are used for quite different things - tabMoved indicates that a tab has moved in QTabBar, but moveTab tells the tab widget to move the tab.

One could of course just revert your commit to fix this, but I thought there might be a nicer solution - using signals and slots to do tell the tab widget to move the tab in the tab bar is maybe not the best way to do it.

I thought that one could just call QTabBar::moveTab(int, int) in KTabBar::mouseMoveEvent rather than emitting KTabBar's moveTab signal - the tab widget gets informed automatically about the move operation then, and the connection you've modified could be removed. However, this did not quite work for me - the tab bar looked a bit messed up until I forced it to redraw by resizing the window. I don't have much time to look further into this before the beta tagging - do you have an idea?

Sorry for the late answer. I fixed it because i fixed many runtime warnings about obsolete signals.

I'm currently trying to find the source of the moveTab() signal that previously was used and is obsoleted according to my initial commit.

If i find it (again) i will come back here. Until then i'm ok with reverting my change.

SVN commit 1081586 by freininghaus:

Revert r1011036 to restore MMB tab moving in
KTabBar/KTabWidget. Furthermore, this patch adds a unit test and
clarifies the API docs.

Fix will be in 4.4 RC 3.

BUG: 214646


 M  +49 -0     tests/ktabwidget_unittest.cpp  
 M  +10 -3     widgets/ktabbar.h  
 M  +1 -1      widgets/ktabwidget.cpp  
 M  +4 -0      widgets/ktabwidget.h  


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

SVN commit 1081589 by freininghaus:

Forwardport r1081586 to trunk:

Revert r1011036 to restore MMB tab moving in
KTabBar/KTabWidget. Furthermore, this patch adds a unit test and
clarifies the API docs.

CCBUG: 214646


 M  +49 -0     tests/ktabwidget_unittest.cpp  
 M  +10 -3     widgets/ktabbar.h  
 M  +1 -1      widgets/ktabwidget.cpp  
 M  +4 -0      widgets/ktabwidget.h  


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