Qt-interest Archive, September 2004
Simple slots question
Message 1 in thread
Is it "good practice" to make all operations in classes derived from
QObject slots? I have seen a few examples that follow this approach ...
is there any particular benefit to this, especially with private operations?
Yes, I am new to Qt :-)
Thanks,
Tim
Message 2 in thread
I do not think it is a good practice. You should use slots when needed,
that is for operations that you would like to attach to signals. That
applied to both, public and private methods. For example, if you have
such a function:
bool isActive();
which benefits will you find on making that a slot?
My advice is declare as slots only the functions you want to be
connected to signals and, if another day you need some function to be a
slot, then "refactor", that is, declare that function as slot.
jordi
Tim Ferrell wrote:
> Is it "good practice" to make all operations in classes derived from
> QObject slots? I have seen a few examples that follow this approach
> ... is there any particular benefit to this, especially with private
> operations?
>
> Yes, I am new to Qt :-)
>
> Thanks,
> Tim
>
> --
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 3 in thread
something safe is to declare Q_OBJECT macro in class asssociated with
some design and moc it.
this because when you create a class and latter add slot, sometime you
forget to moc header and so search what's the cimpil problem...
Jordi Massaguer Pla wrote:
> I do not think it is a good practice. You should use slots when
> needed, that is for operations that you would like to attach to
> signals. That applied to both, public and private methods. For
> example, if you have such a function:
>
> bool isActive();
>
> which benefits will you find on making that a slot?
>
> My advice is declare as slots only the functions you want to be
> connected to signals and, if another day you need some function to be
> a slot, then "refactor", that is, declare that function as slot.
>
> jordi
>
> Tim Ferrell wrote:
>
>> Is it "good practice" to make all operations in classes derived from
>> QObject slots? I have seen a few examples that follow this approach
>> ... is there any particular benefit to this, especially with private
>> operations?
>>
>> Yes, I am new to Qt :-)
>>
>> Thanks,
>> Tim
>>
>> --
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>>
>
> --
> List archive and information: http://lists.trolltech.com/qt-interest/
>
Message 4 in thread
It is safe but I do not think a good practice. Declaring Q_OBJECT when
you don't need it makes your code Qt-dependent and you can not use your
class in a project without Qt unless you delete the macro (i.e
unit-testing your class using a framework without Qt support).
veronique.lefrere@c-s.fr wrote:
> something safe is to declare Q_OBJECT macro in class asssociated with
> some design and moc it.
> this because when you create a class and latter add slot, sometime you
> forget to moc header and so search what's the cimpil problem...
>
>
> Jordi Massaguer Pla wrote:
>
>> I do not think it is a good practice. You should use slots when
>> needed, that is for operations that you would like to attach to
>> signals. That applied to both, public and private methods. For
>> example, if you have such a function:
>>
>> bool isActive();
>>
>> which benefits will you find on making that a slot?
>>
>> My advice is declare as slots only the functions you want to be
>> connected to signals and, if another day you need some function to be
>> a slot, then "refactor", that is, declare that function as slot.
>>
>> jordi
>>
>> Tim Ferrell wrote:
>>
>>> Is it "good practice" to make all operations in classes derived from
>>> QObject slots? I have seen a few examples that follow this approach
>>> ... is there any particular benefit to this, especially with private
>>> operations?
>>>
>>> Yes, I am new to Qt :-)
>>>
>>> Thanks,
>>> Tim
>>>
>>> --
>>> List archive and information: http://lists.trolltech.com/qt-interest/
>>>
>>>
>>
>> --
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>
> --
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>