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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel