some work and api design on plasma2

[Mark]

On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin <notmart at gmail.com> wrote:
> Hi all,
>
> as you know the hardest thing, by far in plasma2 is splitting anything related
> to qgraphics* out of libplasma.
> that basically means graphics-less Applet, Containment and Corona, and this
> will have to happen in time for frameworks5, regardless having a qml2 version
> ready or not (i would go as far as  putting that as completely secondary and
> eventually releasing it only in a second time)
> the quantity of work still to be done is huge, and the time not much.
>
> i have now a branch in kdelibs: plasma/mart/simpleapplet
>
> it's a branch of frameworks and had the following work:
>
> corona, containment and applet are for now disabled from build (libplsmaqgv
> that's the legacy qgraphics* library doesn't build atm)
> there are AbsrtactApplet and AbstractContainment: they are still not finished,
> but are intended to be qobject-only versions, with only the logic. all the
> other parts in libplasma that were depending from applet or containment are
> now using abstractapplet or abstractcontainment.
>
>
> problem: the old qgv based Applet and Containment should inherit from
> AbstractApplet and AbstractContainment, but this means abstract* cannot be
> QObjects, but they need some signals and slots (besides needing to be able to
> be loaded as plugins: required to be qobject?)
>
> so basically there are 2 options:
> a) abstractapplet/containment are not qobjects (exposing a qobject member for
> needed signals/slots? kinda ugly)
>
> b) make them qobjects and make Applet/Containment not a subclass but having
> abstractapplet as a member property, so that would become a sort of a "model"
> (kinda ugly as well)
>
> in both cases it may be needed and a completely separated implementation of
> Corona (that in turn poses the same problem, at the moment it has a partial
> separation to a CoronaBase class that is following the model b) approach, but
> can be changed)
>
>
> comments? suggestions? volunteers for the work? :p
>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Hi,

Finally something where i can share my knowledge :)
Recently (last week!) i had this issue with inheritance and QObject as
well. I wanted to make an abstract class (an interface actually) with
signals. That last part required QObject and adding that makes t he
compiler go nuts since each implementation would also inherit from
something that has QObject. An example:

class MyInterface : public QObject
{
    Q_OBJECT

signals:
    virtual void mySignal() =0;
}

class Implementation : public QFile
{
    Q_OBJECT

signals:
    void mySignal();
}

That fails because QFile also has QObject.
After that i went googling for a while to figure out how i could use
inheritance but somehow avoid this issue.

Turns out that i had to use
Q_DECLARE_INTERFACE
Q_INTERFACES
which was described here:
http://stackoverflow.com/questions/3726716/qt-interfaces-or-abstract-classes-and-qobject-cast/3726868#3726868

With that in mind the above example needs to be written as follows:
class MyInterface // NO QObject inheritance!
{
signals:
    virtual void mySignal() =0;
}
Q_DECLARE_INTERFACE(MyInterface, "MyInterface/1.0")

class Implementation : public QFile, public MyInterface
{
    Q_OBJECT
    Q_INTERFACES(MyInterface)

signals:
    void mySignal();
}

That compiles and works. Yet, you still can't use your signals. In
order for the signals to work you can do 2 things now.
1:
casting to QObject like so:
MyInterface* test = new Implementation();
QObject::connect(dynamic_cast<QObject*>(test), SIGNAL(mySignal()), SLOT(...));

2:
By following this http://stackoverflow.com/a/3260487 which results a
signal being done this way (assuming you adjust the MyInterface
according to that answer):
MyInterface* test = new Implementation();
QObject::connect(test->object(), SIGNAL(mySignal()), SLOT(...));

I actually tried the first one (and am using it right now) and that
works well. I haven't tried the second one though.

So there you go, an answer to your question for signals in a abstract
class. Hope that helps.

Good luck,
Mark