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
