Qt-interest Archive, June 2007
Plugins with signals and slots
Pages: Prev | 1 | 2 | Next
Message 1 in thread
What is the correct way to define a plugin with signals and slots, that can
later be connected?
Arne
--
[ signature omitted ]
Message 2 in thread
> What is the correct way to define a plugin with signals and slots, that
> can
> later be connected?
>
> Arne
>
> --
> [--- PGP key FD05BED7 --- http://www.root42.de/ ---]
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
If it is possible (Never tried it) by defining signals and slots in your
interface file.. But what is correct.. If the compiler doesn't choke on
it, it is correct, right? (The compiler is always right.)
--
[ signature omitted ]
Message 3 in thread
Peter M. Groen wrote:
>> What is the correct way to define a plugin with signals and slots, that
>> can
>> later be connected?
>
> If it is possible (Never tried it) by defining signals and slots in your
> interface file.. But what is correct.. If the compiler doesn't choke on
> it, it is correct, right? (The compiler is always right.)
Replace `correct` with `most elegant`. Problem with the above approach is,
that the interface must not be derived from QObject, so signals and slots
have to be defined as member functions, which is not elegant, and involves
some trickery afterwards in the derived classes.
Arne
--
[ signature omitted ]
Message 4 in thread
If you are using Qt plugins system, then you propably know that
QPluginLoader returns QObject. If it is QObject, then it has whole
metainfo in it (like for example list of signals and slots). You can
just connect to them, even if you didn't declare them in your interface
On Jun 20, 2007, at 10:53 AM, Arne Schmitz wrote:
> Peter M. Groen wrote:
>
>>> What is the correct way to define a plugin with signals and
>>> slots, that
>>> can
>>> later be connected?
>>
>> If it is possible (Never tried it) by defining signals and slots
>> in your
>> interface file.. But what is correct.. If the compiler doesn't
>> choke on
>> it, it is correct, right? (The compiler is always right.)
>
> Replace `correct` with `most elegant`. Problem with the above
> approach is,
> that the interface must not be derived from QObject, so signals and
> slots
> have to be defined as member functions, which is not elegant, and
> involves
> some trickery afterwards in the derived classes.
>
> Arne
>
> --
> [--- PGP key FD05BED7 --- http://www.root42.de/ ---]
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx
> with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
--
[ signature omitted ]
Message 5 in thread
Kamil Klimek wrote:
> If you are using Qt plugins system, then you propably know that
> QPluginLoader returns QObject. If it is QObject, then it has whole
> metainfo in it (like for example list of signals and slots). You can
> just connect to them, even if you didn't declare them in your interface
Ah, that's cool! Thanks!
Arne
--
[ signature omitted ]
Message 6 in thread
On 20.06.07 10:53:23, Arne Schmitz wrote:
> Peter M. Groen wrote:
>
> >> What is the correct way to define a plugin with signals and slots, that
> >> can
> >> later be connected?
> >
> > If it is possible (Never tried it) by defining signals and slots in your
> > interface file.. But what is correct.. If the compiler doesn't choke on
> > it, it is correct, right? (The compiler is always right.)
>
> Replace `correct` with `most elegant`. Problem with the above approach is,
> that the interface must not be derived from QObject, so signals and slots
> have to be defined as member functions, which is not elegant, and involves
> some trickery afterwards in the derived classes.
Exactly what trickery are you talking about? We use the following in
KDevelop without any problems:
class IFace {
public:
virtual ~IFace();
virtual void someFunc() = 0;
public slots:
virtual void slotDoSomething() = 0;
signals:
void fooSignal();
}
class Impl : public QObject, public IFace
{
public:
Impl();
~Impl();
void someFunc();
public slots:
void slotDoSomething();
signals:
void fooSignal();
}
Then Impl can emit fooSignal() in any of its methods. You can use
the QObject-pointer for Impl that you get when loading the plugin to
connect signals and slots. I don't really see a proble that needs
"trickery".
The only downside is that you need to "copy" the signal/slot definition
from the IFace which makes this a bit un-elegant.
Andreas
--
[ signature omitted ]
Message 7 in thread
Andreas Pakulat wrote:
> On 20.06.07 10:53:23, Arne Schmitz wrote:
>
>> Peter M. Groen wrote:
>>
>>
>>>> What is the correct way to define a plugin with signals and slots, that
>>>> can
>>>> later be connected?
>>>>
>>> If it is possible (Never tried it) by defining signals and slots in your
>>> interface file.. But what is correct.. If the compiler doesn't choke on
>>> it, it is correct, right? (The compiler is always right.)
>>>
>> Replace `correct` with `most elegant`. Problem with the above approach is,
>> that the interface must not be derived from QObject, so signals and slots
>> have to be defined as member functions, which is not elegant, and involves
>> some trickery afterwards in the derived classes.
>>
>
> Exactly what trickery are you talking about? We use the following in
> KDevelop without any problems:
>
> class IFace {
> public:
> virtual ~IFace();
> virtual void someFunc() = 0;
> public slots:
> virtual void slotDoSomething() = 0;
> signals:
> void fooSignal();
> }
>
> class Impl : public QObject, public IFace
> {
> public:
> Impl();
> ~Impl();
> void someFunc();
> public slots:
> void slotDoSomething();
> signals:
> void fooSignal();
> }
>
> Then Impl can emit fooSignal() in any of its methods. You can use
> the QObject-pointer for Impl that you get when loading the plugin to
> connect signals and slots. I don't really see a proble that needs
> "trickery".
>
> The only downside is that you need to "copy" the signal/slot definition
> from the IFace which makes this a bit un-elegant.
>
>
>
This trickery can be avoided by using a factory pattern for your
interfaces that create the "real" objects you want to plugin into your
app. Another cool side effect is when you use factories is you can now
create N objects for one plugin.
I usually do something like:
class AbstractPluginFactory
{
public:
virutal AbstractClass* createMyClass()=0;
};
Q_DECLARE_INTERFACE(AbstractPluginFactory)
class AbstractClass : public QObject
{
Q_OBJECT
public:
//Everything is legal here and inherited correctly
};
class MyClass : public AbstractClass
{
Q_OBJECT
public:
//Do whatever you usually do for QObjects
};
class MyPluginFactory : public QObject, public AbstractPluginFactory
{
Q_OBJECT
Q_INTERFACES(AbstractPluginFactory)
public:
virutal AbstractClass* createMyClass() { return new MyClass };
};
Good Luck,
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
url:http://www.ics.com
version:2.1
end:vcard
Message 8 in thread
Hi all,
I am uma..new to qt development..
I would like to add one html file which has links to pdf files,..
Would any body knows how to incorporate html page in QT...
Thanks and regards
Uma.
--
[ signature omitted ]
Message 9 in thread
On 20.06.07 20:15:53, Rao, UmaMaheswara(GE Healthcare) wrote:
>
> Hi all,
>
> I am uma..new to qt development..
>
> I would like to add one html file which has links to pdf files,..
>
> Would any body knows how to incorporate html page in QT...
See the documentation for QTextEdit.
Andreas
--
[ signature omitted ]
Message 10 in thread
I looked at the QTextEdit documentation and I saw now reference to PDF.
I is somewhere else?
-----Original Message-----
From: Andreas Pakulat [mailto:apaku@xxxxxx]
Sent: Wednesday, June 20, 2007 11:21
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Would any body knows how to incorporate pdf files in QT..
On 20.06.07 20:15:53, Rao, UmaMaheswara(GE Healthcare) wrote:
>
> Hi all,
>
> I am uma..new to qt development..
>
> I would like to add one html file which has links to pdf files,..
>
> Would any body knows how to incorporate html page in QT...
See the documentation for QTextEdit.
Andreas
--
[ signature omitted ]
Message 11 in thread
On 20.06.07 15:14:18, Miller, Douglas K. CONT NAVAIR 2109, 1, N139 wrote:
> I looked at the QTextEdit documentation and I saw now reference to PDF.
> I is somewhere else?
I understood that you wanted to display a html page with links to pdf
files. Displaying html pages can be done with QTextEdit. There's no
widget that can display PDF files in Qt itself. But there's
libpoppler a pdf rendering library, which also has qt4 and qt3 versions.
Andreas
--
[ signature omitted ]
Message 12 in thread
On 6/20/07, Justin Noel <justin@xxxxxxx> wrote:
>
> This trickery can be avoided by using a factory pattern for your
> interfaces that create the "real" objects you want to plugin into your
> app. Another cool side effect is when you use factories is you can now
> create N objects for one plugin.
I typically do the same thing. It's a couple minutes of extra work up
front (creating the wrapper class), but it's well worth it.
--
[ signature omitted ]
Message 13 in thread
Justin Noel schrieb:
> Andreas Pakulat wrote:
>> On 20.06.07 10:53:23, Arne Schmitz wrote:
>>
>>> Peter M. Groen wrote:
>>>
>>>
>>>>> What is the correct way to define a plugin with signals and slots,
>>>>> that
>>>>> can
>>>>> later be connected?
>>>>>
>>>> If it is possible (Never tried it) by defining signals and slots in
>>>> your
>>>> interface file.. But what is correct.. If the compiler doesn't choke on
>>>> it, it is correct, right? (The compiler is always right.)
>>>>
>>> Replace `correct` with `most elegant`. Problem with the above
>>> approach is,
>>> that the interface must not be derived from QObject, so signals and
>>> slots
>>> have to be defined as member functions, which is not elegant, and
>>> involves
>>> some trickery afterwards in the derived classes.
>>>
>>
>> Exactly what trickery are you talking about? We use the following in
>> KDevelop without any problems:
>>
>> class IFace {
>> public:
>> virtual ~IFace();
>> virtual void someFunc() = 0;
>> public slots:
>> virtual void slotDoSomething() = 0;
>> signals:
>> void fooSignal();
>> }
>>
>> class Impl : public QObject, public IFace
>> {
>> public:
>> Impl();
>> ~Impl();
>> void someFunc();
>> public slots:
>> void slotDoSomething();
>> signals:
>> void fooSignal();
>> }
>>
>> Then Impl can emit fooSignal() in any of its methods. You can use
>> the QObject-pointer for Impl that you get when loading the plugin to
>> connect signals and slots. I don't really see a proble that needs
>> "trickery".
>>
>> The only downside is that you need to "copy" the signal/slot definition
>> from the IFace which makes this a bit un-elegant.
>>
>>
>>
>
> This trickery can be avoided by using a factory pattern for your
> interfaces that create the "real" objects you want to plugin into your
> app. Another cool side effect is when you use factories is you can now
> create N objects for one plugin.
>
> I usually do something like:
>
> class AbstractPluginFactory
> {
> public:
> virutal AbstractClass* createMyClass()=0;
> };
> Q_DECLARE_INTERFACE(AbstractPluginFactory)
>
> class AbstractClass : public QObject
> {
> Q_OBJECT
> public:
> //Everything is legal here and inherited correctly
> };
>
> class MyClass : public AbstractClass
> {
> Q_OBJECT
> public:
> //Do whatever you usually do for QObjects
> };
>
> class MyPluginFactory : public QObject, public AbstractPluginFactory
> {
> Q_OBJECT
> Q_INTERFACES(AbstractPluginFactory)
> public:
> virutal AbstractClass* createMyClass() { return new MyClass };
> };
I've tried the last few days the same and got a Problem with the class
which you named 'AbstractClass'. Because when I load the plugin I got
errors 'undefined symbol' for all members of the 'AbstractClass'. (I
have 'normal' and 'virtual' methods in my 'AbstractClass').
Can somebody tell me where the problem could be?
Stefan
--
[ signature omitted ]
Message 14 in thread
Weinzierl Stefan wrote:
> Justin Noel schrieb:
>
>> Andreas Pakulat wrote:
>>
>>> On 20.06.07 10:53:23, Arne Schmitz wrote:
>>>
>>>
>>>> Peter M. Groen wrote:
>>>>
>>>>
>>>>
>>>>>> What is the correct way to define a plugin with signals and slots,
>>>>>> that
>>>>>> can
>>>>>> later be connected?
>>>>>>
>>>>>>
>>>>> If it is possible (Never tried it) by defining signals and slots in
>>>>> your
>>>>> interface file.. But what is correct.. If the compiler doesn't choke on
>>>>> it, it is correct, right? (The compiler is always right.)
>>>>>
>>>>>
>>>> Replace `correct` with `most elegant`. Problem with the above
>>>> approach is,
>>>> that the interface must not be derived from QObject, so signals and
>>>> slots
>>>> have to be defined as member functions, which is not elegant, and
>>>> involves
>>>> some trickery afterwards in the derived classes.
>>>>
>>>>
>>> Exactly what trickery are you talking about? We use the following in
>>> KDevelop without any problems:
>>>
>>> class IFace {
>>> public:
>>> virtual ~IFace();
>>> virtual void someFunc() = 0;
>>> public slots:
>>> virtual void slotDoSomething() = 0;
>>> signals:
>>> void fooSignal();
>>> }
>>>
>>> class Impl : public QObject, public IFace
>>> {
>>> public:
>>> Impl();
>>> ~Impl();
>>> void someFunc();
>>> public slots:
>>> void slotDoSomething();
>>> signals:
>>> void fooSignal();
>>> }
>>>
>>> Then Impl can emit fooSignal() in any of its methods. You can use
>>> the QObject-pointer for Impl that you get when loading the plugin to
>>> connect signals and slots. I don't really see a proble that needs
>>> "trickery".
>>>
>>> The only downside is that you need to "copy" the signal/slot definition
>>> from the IFace which makes this a bit un-elegant.
>>>
>>>
>>>
>>>
>> This trickery can be avoided by using a factory pattern for your
>> interfaces that create the "real" objects you want to plugin into your
>> app. Another cool side effect is when you use factories is you can now
>> create N objects for one plugin.
>>
>> I usually do something like:
>>
>> class AbstractPluginFactory
>> {
>> public:
>> virutal AbstractClass* createMyClass()=0;
>> };
>> Q_DECLARE_INTERFACE(AbstractPluginFactory)
>>
>> class AbstractClass : public QObject
>> {
>> Q_OBJECT
>> public:
>> //Everything is legal here and inherited correctly
>> };
>>
>> class MyClass : public AbstractClass
>> {
>> Q_OBJECT
>> public:
>> //Do whatever you usually do for QObjects
>> };
>>
>> class MyPluginFactory : public QObject, public AbstractPluginFactory
>> {
>> Q_OBJECT
>> Q_INTERFACES(AbstractPluginFactory)
>> public:
>> virutal AbstractClass* createMyClass() { return new MyClass };
>> };
>>
>
> I've tried the last few days the same and got a Problem with the class
> which you named 'AbstractClass'. Because when I load the plugin I got
> errors 'undefined symbol' for all members of the 'AbstractClass'. (I
> have 'normal' and 'virtual' methods in my 'AbstractClass').
>
> Can somebody tell me where the problem could be?
>
>
Your plugin needs to link directly against the lib that defines the
symbols for AbstractClass. You can't have any hanging symbols in the .so
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
url:http://www.ics.com
version:2.1
end:vcard
Message 15 in thread
Justin Noel schrieb:
[...]
>>
>> I've tried the last few days the same and got a Problem with the class
>> which you named 'AbstractClass'. Because when I load the plugin I got
>> errors 'undefined symbol' for all members of the 'AbstractClass'. (I
>> have 'normal' and 'virtual' methods in my 'AbstractClass').
>>
>> Can somebody tell me where the problem could be?
>>
>>
>
> Your plugin needs to link directly against the lib that defines the
> symbols for AbstractClass. You can't have any hanging symbols in the .so
But my AbstractClass comes from the Application which loads the Plugin.
Stefan
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
