KTabWidget vs QTabWidget

Hey all,

In looking into fixing the remaining issues in Okular's frameworks
branch I realized that in part of the effort to port it away from
KDELibs4Support it got some functionality removed. It was ported from
KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag
and drop the way KTabWidget did. In looking at the KTabWidget
documentation on it still says that KTabWidget is
preferred over QTabWidget [1]. If that's the case why did it end up in

In reading Qt documentation about drag and drop [2] it seems that you
need to subclass widgets in order to specify any additional mime types
that should be handled by a drop event (which okular made use of so
you could drop documents on it's tab bar to open them). Without
KTabWidget we lose that feature completely unless we subclass
QTabWidget (which we have in KTabWidget... so why not just use it...).
Am I missing something? If not I suggest we reconsider and maybe
move/copy? KTabWidget into KF5::WidgetsAddons as it still provides
functionality we want/need in some cases. I'm not sure what would be
BC or SC in this case tbh (or maybe users of KTabWidget should just
keep using KDELibs4Support?)


1. <a href="" title=""></a>
2. <a href="" title=""></a>


Re: KTabWidget vs QTabWidget

By David Faure at 09/19/2015 - 10:49

On Friday 18 September 2015 18:46:24 Jeremy Whiting wrote:
Nobody took the time to update the documentation of all the classes
that were moved to kdelibs4support.
So as always: trust the code more than the documentation.

To be clear: QTabWidget supports dnd-to-reorder tabs, but that's not
what you're after, you want DnD of URLs, right?

It takes about 10 lines of code in a QTabWidget subclass, but of course
I have no objection to this being provided by KF5 for convenience.
However, *not* as a QTabWidget subclass then. We moved away from that design
because it creates confusion (when to use QTabWidget and when to use KTabWidget)
and makes things less flexible. Instead, I suggest that you want a decorator,
much like KDragWidgetDecorator in kwidgetaddons, but for drops of URLs.
The decorator would install event filters for DragEnter and Drop, check for URLs,
decode on drop, emit a signal. The only problem is: how would we tell the decorator
that we only want drops "in the empty area next to the tabbar" and not everywhere
on the tabwidget... (I assume this is what you want, right?).

(I'm keeping the CC to kde-core-devel so its readers can see this has been
answered, but I suggest we now followup on kde-frameworks-devel only).

Re: KTabWidget vs QTabWidget

By =?utf-8?Q?Thoma... at 09/19/2015 - 03:19

On Samstag, 19. September 2015 02:46:24 CEST, Jeremy Whiting wrote:
Wild guess: the class was moved, but nobody took a close look at the comments, so the API docu remained the same and on Qt4 level.

No, you can also install an eventfilter (on QTabBar/QTabWidget, the feature code was/is mostly in KTabBar, KTabWidget largely only forwards it)

Probably because it contains much additional code and dropping mime is too rare - and usually only required from one location.
The effort to bind the signals isn't much different from providing an eventfilter, QTabBar has ::tabAt(), so you already have the index for the event position.

"move". Having the same symbol in KWidgetAddons and kde4libssupport is gonna break things - badly.

I assume this is why the support lib exists - you can keep the widget until you ported away :-P


Re: KTabWidget vs QTabWidget

By Gilles Caulier at 09/19/2015 - 03:40

Into digiKam, i do exactly a pure Qt5 port of KTabWidget to QTabWidget,
especially about D&D.

Look my commit :

<a href=";a=commit&amp;h=11b5e18d24d80a1bf34fdcc78064a7cb8a26fabc" title=";a=commit&amp;h=11b5e18d24d80a1bf34fdcc78064a7cb8a26fabc">;a=commit&amp;h=11b5e18d24d80a1bf34fd...</a>


Gilles Caulier

2015-09-19 9:19 GMT+02:00 Thomas L├╝bking <thomas. ... at gmail dot com>: