KTabWidget vs QTabWidget

[David Faure]

On Friday 18 September 2015 18:46:24 Jeremy Whiting wrote:
> 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 api.kde.org it still says that KTabWidget is
> preferred over QTabWidget [1]. If that's the case why did it end up in
> KDELibs4Support?

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.

> 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?)

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).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5