KTabWidget vs QTabWidget

[Thomas Lübking]

Disclaimer: I've no knowledge about the made decision process/intentions.

On Samstag, 19. September 2015 02:46:24 CEST, Jeremy Whiting wrote:
> KTabWidget documentation on api.kde.org it still says that KTabWidget is
> preferred over QTabWidget [1].

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.

> 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

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

> (which we have in KTabWidget... so why not just use 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.

> Am I missing something? If not I suggest we reconsider and maybe
> move/copy?

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

> or maybe users of KTabWidget should just keep using KDELibs4Support?

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

Cheers,
Thomas