KTabWidget vs QTabWidget

[David Faure]

On Monday 21 September 2015 20:16:01 Jeremy Whiting wrote:
> David,
> 
> I've been considering what you mean. I think I understand, but wanted
> to check before I spend a bit of time trying to implement what you
> described. Does the class below fit what you are considering?
> 
> class KDropWidgetDecorator: public QObject {
> Q_OBJECT
>  public:
>   void installEventFilter(QWidget *);

installEventFilter is an existing QObject method, better just do it
in the KDropWidgetDecorator constructor.

>  signals:
> void receivedDropEvent (QDropEvent *);
> void testCanDecode (const QDragMoveEvent *e, bool &accept);

non-const refs in signals are an ugly hack.
You don't know if there is going to be 0, 1 or N slots, and the ref only makes sense for 1.

Instead I suggest:
* a virtual method, but that means deriving from the decorator, not great
* a virtual method in a separate interface class (so you can just make your
main widget implement that interface)
* a std::function, so the caller can pass a lambda or a static function

Alternatively, call it KUrlDropWidgetDecorator and make it support urls
out of the box. This is the most common use case all over KDE, isn't it?

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