KTabWidget vs QTabWidget

[Gilles Caulier]

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

Look my commit :

https://quickgit.kde.org/?p=digikam.git&a=commit&h=11b5e18d24d80a1bf34fdcc78064a7cb8a26fabc

Best

Gilles Caulier

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

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150919/9612a20f/attachment.htm>