In looking at what is using KTabWidget it seems there's a drop in
replacement for what we are doing in
http://lxr.kde.org/source/extragear/office/kile/src/kileviewmanager.h
in DropWidget towards the bottom. Could/should we simply copy that to
kwidgetsaddons and rename it KDropWidgetDecorator and use it where old
code was using KTabWidget?
BR,
Jeremy
On Tue, Sep 22, 2015 at 12:47 AM, David Faure <fa...@kde.org> wrote:
> 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
