Re: [Interest] Are slots even needed these days?

[Nye]

On Fri, May 13, 2016 at 2:43 PM, d3fault  wrote:


> It's to work around the diamond inheritance problem, so yea admittedly
> it's ugly. Know a cleaner way? I'm all ears.
>

Declare your signals directly into the classes that provide them and
connect compatible methods, that'd be the cleaner way. But, yes, I admit,
it doesn't work with an abstract class like you want.


> They can be pure virtual in the interface, just don't mark them virtual in
> the derived classes and you won't get that warning.
>

I would assume this warning was put there for a reason by the Qt devs,
wouldn't you?


> If they're both reinterpret_casts then it compiles but segfaults.
>

Of course it segfaults, these aren't POD structures, they have pointers to
the virtual tables, you can't just reinterpret_cast from one type to the
other. That's why dynamic_cast was invented in the first place. If you
properly cast to QObject * (that is with dynamic_cast) the result is like
from the previous connect: "QObject::connect: signal not found in A"


> Please download the attachment and test out your connect statements (both
> compilation and execution) before responding with another attempt.
>

I had duly noted that the snippet I provided wan't tested, so there's no
need to get overly excited.

 RTTI has overhead, and while you're right that "forcing the interface to
> know about implementation details of derived classes" is usually a bad
> idea, in this case the goal is to make a "signals & slots interface", so
> it's guaranteed that all derived classes will ultimately inherit QObject.
>

It does, but so does the moc generated data. It's how qobject_cast works
without RTTI in the first place, it basically does what RTTI does, and even
some more.

As a side note, I remembered how you can cast to the interface without the
need of RTTI:
Declare the interface with Q_DECLARE_INTERFACE and list in the Q_INTERFACES
macro the interfaces you implement. Then you can do qobject_cast(a); (where a is QObject *).
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[d3fault]

For completeness I've attached a minimal compiling + working example of a
"Signals & Slots Interface" that requires the Qt4-style connect syntax in
order to use, which also means the interface implementers must use the
"slots:" section in their class declaration/header (as per the subject of
these emails).


On Sun, May 8, 2016 at 4:41 AM, Nye  wrote
>
> I suppose, but this very much smells like abusing the API, forgive me from
> saying.
>

It's to work around the diamond inheritance problem, so yea admittedly it's
ugly. Know a cleaner way? I'm all ears.



> I had made some testing and moc complains (rightfully so) that signals
> can't be virtual.
>

They can be pure virtual in the interface, just don't mark them virtual in
the derived classes and you won't get that warning.



> QObject::connect(a->asQObject(), static_cast (QObject::*)()>(::someSignal), b->asQObject(),
> reinterpret_cast(::someSlot));
>

Does not compile. If they're both reinterpret_casts then it compiles but
segfaults. Please download the attachment and test out your connect
statements (both compilation and execution) before responding with another
attempt.


Perhaps you should consider enabling it then (provided you
> compiler/platform supports it). No RTTI, means you cant query for the
> interface implementation and in my opinion toQObject() is much worse, as it
> actually forces the interface to know about implementation details of
> derived classes ... but then,  in the end it's your choice.
>

 RTTI has overhead, and while you're right that "forcing the interface to
know about implementation details of derived classes" is usually a bad
idea, in this case the goal is to make a "signals & slots interface", so
it's guaranteed that all derived classes will ultimately inherit QObject.


Lastly, I'll mention that I didn't come up with any of these techniques. I
picked them up over the years from random blogs/forums/IRC/lists/etc.

d3fault

>


SignalsSlotsInterfaceExample.7z
Description: application/7z-compressed
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Sina Dogru]

Hello,

2016-05-07 10:34 GMT+03:00 d3fault :

> ...
>
> ^code is pseudo/buggy, but mostly correct. also I'm aware that this
> oversimplified example wouldn't suffer from the diamond inheritance
> problem... but the diamond inheritance problem does frequently show up when
> using signals/slots interfaces, so the above is usually what a solution
> looks like
>

I guess you are talking about "virtual inheritance with QObject"? As
Meta-Object Compiler docs

says,  "Virtual inheritance with QObject
 is *not* supported.".

But also if you are writing an abstract base class which has a signal and
slots, then this abstraction also contains signal and slots mechanism? So
even this is ABC, it is also possible to derive from QObject? I am sorry I
am not an exprienced C++ or Qt developer but it makes sense to me.

So If I were you I would derive my ABCs from QObject class, so my ABCs
would have signals as "Qt-ish" and would be able to use new signal and slot
syntax. By the way since signals are implemented by the moc, you don't even
have to make them virtual, I am not sure but making a virtual signal also
is not possible.

class Base : public QObject {

Q_OBJECT


public:

explicit Base(QObject *parent = Q_NULLPTR);


signals:

void signalFoo();


public slots:

virtual void slotBar() = 0;

};


class Der : public Base {

Q_OBJECT

public:

explicit Der(QObject *parent = Q_NULLPTR);

public slots:

void slotBar() Q_DECL_OVERRIDE;

};

As an example you can research Qt APIs. For example QAbstractItemModel
. It is also ABC but since
it uses signals and slots, it also derives from QObject class.

Also if you stay in "inland of Qt" you would not have to use RTTI. For
learning more about how Qt uses multiple inheritance there is a great
article  about it from ICS.

Cheers,
Sina
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Nye]

>
> query for the interface implementation
>

To be read as: "query for the interface being implemented
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Nye]

On Sun, May 8, 2016 at 8:27 AM, d3fault  wrote:
>
> You're right, my example didn't suffer from the diamond inheritance
> problem. But suppose you want to inherit from a QWidget derived class (or
> any of the QObject derived classes in Qt xD) in addition to the
> signals/slots interface: if the interface itself derives from QObject,
> you'd have diamond inheritance.
>

I suppose, but this very much smells like abusing the API, forgive me from
saying. I had made some testing and moc complains (rightfully so) that
signals can't be virtual.


>
>> QObject * a = new A;
>> QObject * b = new B;
>> QObject::connect(a, A::someSignal, b, B::someSlot);
>>
>> should be working just fine.
>>
>
> Yes it works, but you're no longer using an interface when you mention A
> or B [in the connect statement].
>


This compiles okay (and should probably be working as well, haven't tested
it though):

QObject * a = new A;
QObject * b = new B;
QObject::connect(a, static_cast(::someSignal), b,
reinterpret_cast(::someSlot));


Note however the ugly casts! (the first one is simply because of the
implicit upcasting, so if a is A * as it'd normally be it wouldn't be
necessary)

Still, I hold to my statement that this really looks like abusing the
API (no matter the syntax used) ...


Interface doesn't inherit from QObject, so qobject_cast doesn't work. I
> don't compile with RTTI, so dynamic_cast is out.
>

Perhaps you should consider enabling it then (provided you
compiler/platform supports it). No RTTI, means you cant query for the
interface implementation and in my opinion toQObject() is much worse, as it
actually forces the interface to know about implementation details of
derived classes ... but then,  in the end it's your choice.

That does not compile. (even with the missing ampersands added it still
> doesn't :-P)
>

Yep, forgot them in the hurry :]

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[d3fault]

On Sat, May 7, 2016 at 2:29 AM, Nye  wrote:

> I don't see any multiple inheritance that forms a diamond. And although I
> like the older syntax better, I don't see what's the problem with the new
> syntax here. This:
>

You're right, my example didn't suffer from the diamond inheritance
problem. But suppose you want to inherit from a QWidget derived class (or
any of the QObject derived classes in Qt xD) in addition to the
signals/slots interface: if the interface itself derives from QObject,
you'd have diamond inheritance.


> QObject * a = new A;
> QObject * b = new B;
> QObject::connect(a, A::someSignal, b, B::someSlot);
>
> should be working just fine.
>

Yes it works, but you're no longer using an interface when you mention A or
B [in the connect statement].


> Plus I don't see a reason for the asQObject() method, qobject_cast or
> dynamic_cast would be much simpler and cleaner.
>

Interface doesn't inherit from QObject, so qobject_cast doesn't work. I
don't compile with RTTI, so dynamic_cast is out.

PS.
>
I just realized you're worried that the functions are virtual. Well this is
> of no consequence, the vtable is respected (if I remember correctly that's
> specified in the standard). So the following should also be working without
> any problem:
>
> QObject::connect(a, Interface::someSignal, b, Interface::someSlot);
>

That does not compile. (even with the missing ampersands added it still
doesn't :-P)


d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Nye]

PS.
I just realized you're worried that the functions are virtual. Well this is
of no consequence, the vtable is respected (if I remember correctly that's
specified in the standard). So the following should also be working without
any problem:

QObject::connect(a, Interface::someSignal, b, Interface::someSlot);
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Nye]

On Sat, May 7, 2016 at 10:34 AM, d3fault  wrote:

> Nobody's mentioned that Qt4-style connect syntax is required to solve the
> diamond inheritance problem that frequently appears when using a
> signals/slots interface.
> [snippet]
>

I don't see any multiple inheritance that forms a diamond. And although I
like the older syntax better, I don't see what's the problem with the new
syntax here. This:

QObject * a = new A;
QObject * b = new B;
QObject::connect(a, A::someSignal, b, B::someSlot);

should be working just fine. Plus I don't see a reason for the asQObject()
method, qobject_cast or dynamic_cast would be much simpler and cleaner.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[d3fault]

Nobody's mentioned that Qt4-style connect syntax is required to solve the
diamond inheritance problem that frequently appears when using a
signals/slots interface.

Ex:

class Interface
{
public:
virtual QObject* asQObject()=0;
protected: //signals
virtual void someSignal()=0;
public: //slots
virtual void someSlot()=0;
};
class A : public QObject, public Interface
{
Q_OBJECT
public:
QObject* asQObject() { return this; }
signals:
void someSignal();
public slots:
void someSlot();
};
class B : public QObject, public Interface
{
Q_OBJECT
public:
QObject* asQObject() { return this; }
signals:
void someSignal();
public slots:
void someSlot();
};

int main()
{
Interface *a = new A;
Interface *b = new B;
connect(a->asQObject(), SIGNAL(someSignal()), b->asQObject(),
SLOT(someSlot())); //not possible using Qt5 style connect syntax, because
someSignal and someSlot are not members of QObject
}


^code is pseudo/buggy, but mostly correct. also I'm aware that this
oversimplified example wouldn't suffer from the diamond inheritance
problem... but the diamond inheritance problem does frequently show up when
using signals/slots interfaces, so the above is usually what a solution
looks like


d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Curtis Mitch]

> -Original Message-
> From: Interest [mailto:interest-bounces+mitch.curtis=theqtcompany.com@qt-
> project.org] On Behalf Of Giuseppe D'Angelo
> Sent: Wednesday, 16 March 2016 3:51 PM
> To: interest@qt-project.org
> Subject: Re: [Interest] Are slots even needed these days?
> 
> Il 16/03/2016 15:24, Nikos Chantziaras ha scritto:
> > I can connect to Foo::bar either way. If I don't intend to ever use
> > the old-style connect syntax, is there a reason to have "public slots:"
> anymore?
> 
> It's still needed if you want to expose those methods to QML / scripting,
> use QMetaObject::invokeMethod, and possibly some other cases.

Perhaps threading, where queued connections are necessary?

> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The
> Qt Experts

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Pönitz]

On Thu, Mar 17, 2016 at 08:23:48AM +0300, Constantin Makshin wrote:
> Another thing I personally don't like in the new connection syntax is
> that it forces signals to be public, making it possible to do all type
> of wonders by faking/simulating events on behalf of other objects.
> 
> For example:
> QLineEdit* edit = new QLineEdit("foo");
> // ...
> edit->textChanged("bar");

You can trigger that emission in Qt 4, too, e.g. using
QMetaObject::invokeMethod(edit, "textChanged", ...)

Andre'

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Till Oliver Knoll]

> Am 16.03.2016 um 23:41 schrieb Bob Hood :
> 
>> On 3/16/2016 3:37 PM, André Pönitz wrote:
>>> On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:
 I can connect to Foo::bar either way. If I don't intend to ever use
 the old-style connect syntax, is there a reason to have "public
 slots:" anymore?
>>> One reason that for me it’s fundamental: Readability of your code !!!
>> It doesn't make the code more readable then a comment
>> 
>>// This is a slot !!!
>>void foo();
> 
> I would argument that it does when you have legions of people out there 
> already conditioned to this:
> 
>...
>public slots:
>void  bar();
>void  foo();
>   

This.

:)

Cheers,
  Oliver___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Bob Hood]

On 3/16/2016 3:37 PM, André Pönitz wrote:

On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:

I can connect to Foo::bar either way. If I don't intend to ever use
the old-style connect syntax, is there a reason to have "public
slots:" anymore?

One reason that for me it’s fundamental: Readability of your code !!!

It doesn't make the code more readable then a comment

// This is a slot !!!
void foo();


I would argument that it /does/when you have legions of people out there 
already conditioned to this:


   ...
   public slots:
   void  bar();
   void  foo();
   ...

instead of:

   ...
   // This is a slot!!!
   void foo();
   ...
   // Oh, hey, this is a slot too!!!
   void bar();
   ...

As a Qt developer, I find the former more elegant and self-documenting.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Pönitz]

On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:
> > I can connect to Foo::bar either way. If I don't intend to ever use
> > the old-style connect syntax, is there a reason to have "public
> > slots:" anymore?
> 
> One reason that for me it’s fundamental: Readability of your code !!!

It doesn't make the code more readable then a comment

   // This is a slot !!!
   void foo();

and since it's not verifiable by the compiler it has
the same effect.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Pönitz]

On Wed, Mar 16, 2016 at 11:02:17PM +, Scott Aron Bloom wrote:
> I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”
> 
> It really lets the methods stand out as slots and signals.. It also means, 
> don’t
> think “sender()” can ever valid if you are not in a “slotXYZ” function.

sender() is pretty much never needed needed with lambda connects, as the sender
can be passed explicitly in the connect() call. This also removes the typical 
need
to qobject_cast<> the sender, as the correct type is available directly.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Thiago Macieira]

On quinta-feira, 17 de março de 2016 08:23:48 PDT Constantin Makshin wrote:
> Another thing I personally don't like in the new connection syntax is
> that it forces signals to be public, making it possible to do all type
> of wonders by faking/simulating events on behalf of other objects.
> 
> For example:
> QLineEdit* edit = new QLineEdit("foo");
> // ...
> edit->textChanged("bar");

You could do it in a round-about way in Qt 4 by using 
QMetaObject::invokeMethod.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Sze Howe Koh]

On 17 March 2016 at 01:03, charleyb123 .  wrote:
> On Wed, Mar 16, 2016 at 10:57 AM, Giuseppe D'Angelo
>  wrote:
>>
>> Il 16/03/2016 17:24, charleyb123 . ha scritto:
>>>
>>> Current slot implementation bridges runtime-reflection capabilities
>>> (provided by QMetaObject), and provides the thread-safe event queue that
>>> bridges "slot-execution" to occur on the "target-thread" for which the
>>> "target-QObject" has "affinity".  Lambdas alone cannot do this -- some
>>> kid of "event-queue" would be required that is "thread-aware" (yes,
>>> could be provided through a library of some kind, that happens to be
>>> what Qt is doing).
>>
>>
>> This thread wasn't talking about lambdas, rather about the "old" connect
>> syntax (SIGNAL/SLOT based) vs the "new" one (PMF based).
>>
>> Anyhow, since you brought lambdas into discussion, you can pass an
>> affinity object for them as well:
>>
>>> https://doc.qt.io/qt-5/qobject.html#connect-5
>>
>>
>
> Ah, thanks:  I misunderstood the thread topic (sorry).  ;-)
>
> Agree that I don't have a use case for the "old" connect syntax anymore
> (fine with me to deprecate it).  I prefer catching errors at compile-time
> with the new syntax.
>
> I've "overheard" some discussions in other circles about ditching all of
> signal/slot in favor of lambdas, and apologies for dragging that into the
> discussion.  It's something I've been thinking about a lot ...   ;-)

There are two things that the new syntax doesn't support: (i) QML
connections, and (ii) default parameters. I haven't used (ii) myself,
but I definitely use (i).

See http://doc.qt.io/qt-5/signalsandslots-syntaxes.html for details.


Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Bob Hood]

On 3/16/2016 5:02 PM, Scott Aron Bloom wrote:
I find them both pretty bad L…  I have spent too much time, looking at other 
people’s code trying to figure out “why” it wont connect, only to realize 
someone had snuck in a “private:” second so moc didn’t generate the slot 
information.


I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”


It really lets the methods stand out as slots and signals.. It also means, 
don’t think “sender()” can ever valid if you are not in a “slotXYZ” function.





I actually prefix my slot method names with "slot_" and signals with "signal_" 
so they are also easily identifiable in the C++ module as I'm looking through 
the code.  More self-documentation.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Scott Aron Bloom]

-Original Message-
From: André Pönitz [mailto:apoen...@t-online.de] 
Sent: Wednesday, March 16, 2016 4:22 PM
To: Scott Aron Bloom
Cc: Bob Hood; interest@qt-project.org
Subject: Re: [Interest] Are slots even needed these days?

On Wed, Mar 16, 2016 at 11:02:17PM +, Scott Aron Bloom wrote:
> I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”
> 
> It really lets the methods stand out as slots and signals.. It also 
> means, don’t think “sender()” can ever valid if you are not in a “slotXYZ” 
> function.

sender() is pretty much never needed needed with lambda connects, as the sender 
can be passed explicitly in the connect() call. This also removes the typical 
need to qobject_cast<> the sender, as the correct type is available directly.

Andre'
=
Ahh.. good point.. Truth is, I have too many side projects stuck using the old 
method.

However, I would still prefer the "slot" and "sig" prefix for clarity...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Giuseppe D'Angelo]

Il 16/03/2016 15:55, Curtis Mitch ha scritto:

Perhaps threading, where queued connections are necessary?


No, you can use the PMF syntax even with queued connections.

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Michael Sué]

Hi,

> is there a reason to have "public slots:" anymore?

If you build dialogs in Qt Designer, you will like the function 
"connectSlotsByName" - called in the generated ui code - to work properly i.e. 
connect correctly just by the names you give your objects and slots.

- Michael.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Alejandro Exojo]

El Wednesday 16 March 2016, Alexander Görtz escribió:
> Yeah wanted to say the same here, the line to connect to a QSpinBox 
> valueChanged is really realy ugly. Mostly because of the ugly syntax of 
> pointers to member functions.

A helper function, qOverload, was added to mitigate this (in 5.7):

http://doc-snapshots.qt.io/qt5-5.7/qtglobal.html#qOverload

Anyway, you can make it decent enough if you organize a bit with an 
intermediate typedef:

using valueChangedSignal = void(QSpinBox::*)(int);
auto valueChangedPointer =
static_cast(::valueChanged);
connect(ui->cacheSize, valueChangedPointer,
this, ::changeCacheLimits);
connect(ui->cacheAge, valueChangedPointer,
this, ::changeCacheLimits);

If you really really need the overloads, and you use them in connections a 
lot, maybe you could even provide the typedef (and the pointer, if you don't 
think it's too much) in your own classes.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Till Oliver Knoll]

> Am 16.03.2016 um 22:37 schrieb André Pönitz :
> 
> On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:
>>> I can connect to Foo::bar either way. If I don't intend to ever use
>>> the old-style connect syntax, is there a reason to have "public
>>> slots:" anymore?
>> 
>> One reason that for me it’s fundamental: Readability of your code !!!
> 
> It doesn't make the code more readable then a comment
> 
>   // This is a slot !!!
>   void foo();

Extend your example to a dozen or so slots and you'd quickly agree that

private slots:
  void foo();
  void bar();
  void baz();
  ...

is much more readable, as compared to, say, repeating your comment or writing 
something like "The following 12 methods are slots (but the 13th isn't! And I'm 
pretty sure that the next Joe Programmer will insert his/her 
"barFooWhichIsNotASlot()"-method randomly between the first 12 methods 
anyway... so whatever!)"

Off course you can try to emphasise your slots with nice ASCII art comments, 
start a fight with your colleagues about the style guide for comments...

Or just write

  private slots:

;)

Cheers,
  Oliver
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Till Oliver Knoll]

> Am 17.03.2016 um 07:39 schrieb André Somers :
> 
> ...
> I find that much more readable than having to look in some signals section to 
> find if there is a notification signal, and then in some slots section to see 
> if the setter is perhaps declared as a slot or not. 

That's an entire different view than what I've had so far (since so far I've 
never used those new "PFM"-style connections. What does it even mean? "Printing 
with Manual Formatting"? ;))

And I must say André's point makes very much sense, too :)

And if I'm not completely mistaken with the old style connections an explicit 
[private|protected|public] slots: section is always needed, in order for the 
moc to recognise the method to be a "slot", no?

Or is this also just syntactical sugar when it comes to /connecting/ a slot 
(ignoring the generated meta data for the moment)?

For instance I know that the private|public specifier has absolutely no 
influence on the "connectability" of a slot, that is you can connect a signal 
to a private slot from /outside/ the class...

Cheers,
  Oliver___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Alexander Görtz]

> Nobody's mentioned the fact that an overridden virtual slot requires an
> absolutely horrid cast in order to use the new PMF syntax.
> 
> -John Weeks
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

Am Mittwoch, 16. März 2016, 10:24:37 CET schrieb John Weeks:

Yeah wanted to say the same here, the line to connect to a QSpinBox 
valueChanged is really realy ugly. Mostly because of the ugly syntax of 
pointers to member functions.


signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Scott Aron Bloom]

From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
Behalf Of Bob Hood
Sent: Wednesday, March 16, 2016 3:42 PM
To: interest@qt-project.org
Subject: Re: [Interest] Are slots even needed these days?

On 3/16/2016 3:37 PM, André Pönitz wrote:


On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:

I can connect to Foo::bar either way. If I don't intend to ever use

the old-style connect syntax, is there a reason to have "public

slots:" anymore?



One reason that for me it’s fundamental: Readability of your code !!!



It doesn't make the code more readable then a comment



   // This is a slot !!!

   void foo();

I would argument that it does when you have legions of people out there already 
conditioned to this:

   ...
   public slots:
   void  bar();
   void  foo();
   ...

instead of:

   ...
   // This is a slot!!!
   void foo();
   ...
   // Oh, hey, this is a slot too!!!
   void bar();
   ...

As a Qt developer, I find the former more elegant and self-documenting.
I find them both pretty bad ☹ …  I have spent too much time, looking at other 
people’s code trying to figure out “why” it wont connect, only to realize 
someone had snuck in a “private:” second so moc didn’t generate the slot 
information.

I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”

It really lets the methods stand out as slots and signals.. It also means, 
don’t think “sender()” can ever valid if you are not in a “slotXYZ” function.

Scott



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Yves Bailly]

A use case for "old-style" slots is when you have dynamic connections, 
established at runtime
from some config file: you get the names of the signals and the slots as 
strings.
With the old style, your code can be as simple as
QObject::connect(foo, signal_name_string, bar, slot_name_string);

With the new style, you would have to manually map the strings to the function 
pointers, hence modifying the connection code each time a new signal or slot is 
added.

--
Yves Bailly
Software developer

> -Original Message-
> From: Interest [mailto:interest-bounces+yves.bailly=verosoftware.com@qt-
> project.org] On Behalf Of Nikos Chantziaras
> Sent: Wednesday, March 16, 2016 3:25 PM
> To: interest@qt-project.org
> Subject: [Interest] Are slots even needed these days?
> 
> Since in modern Qt you connect signals to functions/lambdas, is there a
> reason to declare slots anymore?
> 
> In other words, is there any difference between:
> 
>class Foo: public QObject {
>Q_OBJECT
> 
>public slots:
>void bar();
>};
> 
> and:
> 
>class Foo: public QObject {
>Q_OBJECT
>public:
> 
>void bar();
>};
> 
> I can connect to Foo::bar either way. If I don't intend to ever use the
> old-style connect syntax, is there a reason to have "public slots:"
> anymore?
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Somers]

Op 17/03/2016 om 00:46 schreef Bob Hood:

On 3/16/2016 5:02 PM, Scott Aron Bloom wrote:
I find them both pretty bad L…  I have spent too much time, looking 
at other people’s code trying to figure out “why” it wont connect, 
only to realize someone had snuck in a “private:” second so moc 
didn’t generate the slot information.


I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”


It really lets the methods stand out as slots and signals.. It also 
means, don’t think “sender()” can ever valid if you are not in a 
“slotXYZ” function.





I actually prefix my slot method names with "slot_" and signals with 
"signal_" so they are also easily identifiable in the C++ module as 
I'm looking through the code.  More self-documentation.


And I happen to think that these naming 'conventions' are pure nonsense. 
I really don't care much _how_ a method is called. What's the difference 
between having a method called due to a signal emit and having a method 
called directly? None. I want my methods to be called after what they 
_do_, and not how they are called. What if I I find I have a need to 
call the "slot_" method directly from some other code as well? Should I 
be allowed? Of course I should be! Be the name slot_* suggests issues 
there that don't exist, especially if you don't use sender() any more 
(which has been discouraged for many years already anyway).


And as for people being used to seeing blocks of methods behind a 
'public slots:' access specifyer: sure, but it doesn't add much 
information. It only serves to create some kind of artificial grouping 
of your methods in your declaration that is probably not even all that 
sensible. For instance, if I have a class with many properties on it, I 
think it makes sense to keep the methods related to each property 
together, so I have a quick overview over what methods are available for 
what property. You'd see me writing this:


Foo foo() const;
void setFoo(Foo foo);
Q_SIGNAL fooChanged(Foo foo);

Bar bar() const;
void setBar(Bar bar);
Q_SIGNAL barChanged(Bar bar);

I find that much more readable than having to look in some signals 
section to find if there is a notification signal, and then in some 
slots section to see if the setter is perhaps declared as a slot or not.


For me, Q_SLOT or slots: has little value any more, other than making 
the methods callable in dynamic contexts like QML.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[charleyb123 .]

> Since in modern Qt you connect signals to functions/lambdas, is there a
reason to declare slots anymore?

Interesting question, I've thought about this also.

IMHO, deep consideration is important:

  "slot":  A "slot" is a non-coupling thread-safe execution bridge.

It's already been mentioned in this thread:

Current Qt slots provide (beyond lambdas):

(1) Queued connections
(2) Runtime-reflected connections
(3) Uncoupled connections

Current slot implementation bridges runtime-reflection capabilities
(provided by QMetaObject), and provides the thread-safe event queue that
bridges "slot-execution" to occur on the "target-thread" for which the
"target-QObject" has "affinity".  Lambdas alone cannot do this -- some kid
of "event-queue" would be required that is "thread-aware" (yes, could be
provided through a library of some kind, that happens to be what Qt is
doing).

Because Qt slots can rely upon runtime type-reflection (provided by
QMetaObject), we can also couple signal/slot across two objects where the
code does not include both headers.  This is sometimes important to enable
designs for an "uncoupled-bridge" across components that cannot be coupled.

However, I agree that for the "common-case" (perhaps 80% of the time for
"typical" designs?) that lambdas are just-plain-awesome.

--charley
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Giuseppe D'Angelo]

Il 16/03/2016 15:24, Nikos Chantziaras ha scritto:

I can connect to Foo::bar either way. If I don't intend to ever use the
old-style connect syntax, is there a reason to have "public slots:" anymore?


It's still needed if you want to expose those methods to QML / 
scripting, use QMetaObject::invokeMethod, and possibly some other cases.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Pönitz]

On Thu, Mar 17, 2016 at 08:35:39AM +0100, Till Oliver Knoll wrote:
> > Am 16.03.2016 um 22:37 schrieb André Pönitz :
> > 
> > On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:
> >>> I can connect to Foo::bar either way. If I don't intend to ever
> >>> use the old-style connect syntax, is there a reason to have
> >>> "public slots:" anymore?
> >> 
> >> One reason that for me it’s fundamental: Readability of your code
> >> !!!
> > 
> > It doesn't make the code more readable then a comment
> > 
> >   // This is a slot !!!  void foo();
> 
> Extend your example to a dozen or so slots and you'd quickly agree
> that
> 
> private slots: void foo(); void bar(); void baz(); ...
> 
> is much more readable, as compared to, say, repeating your comment

I thought the comment was silly enough to make clear that I don't
think it has any merits at all, pretty much as marking something
*unnecesarily* as 'slot:' hasn't.

I even copied all the exclamation marks !!!1eleven.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[John Weeks]

Nobody's mentioned the fact that an overridden virtual slot requires an 
absolutely horrid cast in order to use the new PMF syntax.

-John Weeks

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Gian Maxera]

> On 16 Mar 2016, at 14:24, Nikos Chantziaras  wrote:
> 
> Since in modern Qt you connect signals to functions/lambdas, is there a 
> reason to declare slots anymore?
> 
> In other words, is there any difference between:
> 
>  class Foo: public QObject {
>  Q_OBJECT
> 
>  public slots:
>  void bar();
>  };
> 
> and:
> 
>  class Foo: public QObject {
>  Q_OBJECT
>  public:
> 
>  void bar();
>  };
> 
> I can connect to Foo::bar either way. If I don't intend to ever use the 
> old-style connect syntax, is there a reason to have "public slots:" anymore?

One reason that for me it’s fundamental: Readability of your code !!!

Even if it wouldn’t necessary to declare “public slots”, I really strong advice 
to use “slots” because it explicitly say what part of your interface are 
supposed to be attached to a signal and what part not.

It’s very common on my C++ code that only a subset of method are mean to be 
attached to a signal, so make this distinction clear help to understand the 
code and debug it more easily.

Then, I don’t know if there is a real difference on connecting to a function or 
to a explicitly declared slot. But for sure, you cannot use always lambdas. So 
methods acting as slot are necessary.

Ciao,
Gianluca.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Henry Skoglund]

Hi, I thought I was the only one disliking the PMF syntax.
But there's hope, to aid my feeble brain I wrote some macros, so that 
the new syntax resembles the old, but still catching errors in compile time:


#define COMPOSEPMF(QOBJPTR,FUNC) \
::decay::type::FUNC

#define CONNECT(SENDER,FUNC1,RECEIVER,FUNC2) \
connect(SENDER,COMPOSEPMF(SENDER,FUNC1),RECEIVER,COMPOSEPMF(RECEIVER,FUNC2))


Those macros let you write code like this:
...
CONNECT(ui->pushButton,clicked,this,buttonClicked);
...


Less horrid (!) they use std::decay to retrieve the type and prefix it 
to the function, thus setting up correct PMF syntax in all its glory.


However, it wasn't long before I stumbled upon the casting problem, like 
in QCombobox and QSignalMapper. So I had to write 3 more macros:



#define COMPOSECASTPMF(QOBJPTR,ARGS,FUNC) \
static_cast::type::*)(ARGS)> \
(COMPOSEPMF(QOBJPTR,FUNC))

#define CONNECTSCAST(SENDER,ARGS,FUNC1,RECEIVER,FUNC2) \
connect(SENDER,COMPOSECASTPMF(SENDER,ARGS,FUNC1),RECEIVER,COMPOSEPMF(RECEIVER,FUNC2))

#define CONNECTRCAST(SENDER,FUNC1,RECEIVER,ARGS,FUNC2) \
connect(SENDER,COMPOSEPMF(SENDER,FUNC1),RECEIVER,COMPOSECASTPMF(RECEIVER,ARGS,FUNC2))


With those I can write code like so:
...
ui->comboBox->addItems({"Now","is","the","time"});
CONNECTSCAST(ui->comboBox,const QString &,
currentIndexChanged,this,indexChanged);
...
auto sm = new QSignalMapper(ui->pushButton);
CONNECTRCAST(ui->pushButton,clicked,sm,void,map);
...

So yeah, the cast wreaks a bit of a havoc, but you only have to specify 
the casting argument(s), std::decay takes care of prefixing the type.
Note: the macros only support either a sending or a receiving cast, 
hopefully a cast on both sides will never be needed...


Also, beginning now with 5.6 you don't even have to specify CONFIG += 
c++11 in your .pro file, the macros work right out of the box.


Rgrds Henry


On 2016-03-16 18:24, John Weeks wrote:

Nobody's mentioned the fact that an overridden virtual slot requires an

> absolutely horrid cast in order to use the new PMF syntax.



> John Weeks
>

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Giuseppe D'Angelo]

Il 17/03/2016 06:23, Constantin Makshin ha scritto:

Another thing I personally don't like in the new connection syntax is
that it forces signals to be public, making it possible to do all type
of wonders by faking/simulating events on behalf of other objects.

For example:
QLineEdit* edit = new QLineEdit("foo");
// ...
edit->textChanged("bar");


A good counterpart of this is that now a private "slot" is truly 
private, i.e. it's impossible to invoke it externally:


class Foo : public QObject {
Q_OBJECT

Foo() {
 connect(something, , this, ::doFoo);
}
private slots:
void doFoo(); // still reachable and invokable via QMetaObject

private:
void doFoo(); // unreachable from outside
};

Making the signals public is a tradeoff for ease of implementation and 
usage (you would not otherwise be allowed to simply take the address of 
a MF). A check about this could be added to clazy.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Nikos Chantziaras]

On 16/03/16 16:24, Nikos Chantziaras wrote:

Since in modern Qt you connect signals to functions/lambdas, is there a
reason to declare slots anymore?  [...]


Good replies here. So, to sum it up, it seems that slot/signal 
declarations and old-style connect() syntax will continue to have a 
place in Qt due to:


 * QML signals/slots.
 * QObject runtime reflection (invokeMethod() as the most common use.)
 * Easy dynamic connections (signal/slot names unknown at compile time.)
 * Qt Designer automatic signal/slot connection generation.
 * Easy overload resolution (but Qt 5.7 fixes that with qOverload().)

There's also code documenting issues, but these are subjective.

So I'll be keeping the signal/slot declarations. I was considering to 
remove them for the next major version of one of my projects, but it 
would be rather unfortunate to then have to re-introduce some of them 
later on because I want to use QML or might need reflection capabilities.


So using PMF syntax but keeping the signal/slot declarations seems like 
the way to go for me.


Thanks everyone for the helpful feedback! :-)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Somers]

Op 17/03/2016 om 08:35 schreef Till Oliver Knoll:



Am 16.03.2016 um 22:37 schrieb André Pönitz :

On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:

I can connect to Foo::bar either way. If I don't intend to ever use
the old-style connect syntax, is there a reason to have "public
slots:" anymore?

One reason that for me it’s fundamental: Readability of your code !!!

It doesn't make the code more readable then a comment

   // This is a slot !!!
   void foo();

Extend your example to a dozen or so slots and you'd quickly agree that

private slots:
   void foo();
   void bar();
   void baz();
   ...

is much more readable, as compared to, say, repeating your comment or writing something like 
"The following 12 methods are slots (but the 13th isn't! And I'm pretty sure that the next Joe 
Programmer will insert his/her "barFooWhichIsNotASlot()"-method randomly between the 
first 12 methods anyway... so whatever!)"

Off course you can try to emphasise your slots with nice ASCII art comments, 
start a fight with your colleagues about the style guide for comments...

Or just write

   private slots:

;)



I find that just the "private:" part tells me all I need to know in 
terms of code documentation. No need for the comment, nor a need for the 
slots part. If you want to make stuff callable for QML or something like 
that it's another story of course.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Constantin Makshin]

Yes, but, as you said, it's just a hack meant to circumvent C++'s member
visibility system. A rather ugly hack easily detectable by simply grepping
the source code (in a pre-commit hook, for example -- presence of
QMetaObject::invokeMethod() calls outside some parts of Qt itself may be a
good sign that somebody wants to do something weird).
Direct method call, on the other hand, is less likely to both cause
suspicion in anyone looking at the code and to be found by automatic tools.
On Mar 17, 2016 6:37 PM, "Thiago Macieira" 
wrote:

> On quinta-feira, 17 de março de 2016 08:23:48 PDT Constantin Makshin wrote:
> > Another thing I personally don't like in the new connection syntax is
> > that it forces signals to be public, making it possible to do all type
> > of wonders by faking/simulating events on behalf of other objects.
> >
> > For example:
> > QLineEdit* edit = new QLineEdit("foo");
> > // ...
> > edit->textChanged("bar");
>
> You could do it in a round-about way in Qt 4 by using
> QMetaObject::invokeMethod.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Thiago Macieira]

On quinta-feira, 17 de março de 2016 08:56:57 PDT Till Oliver Knoll wrote:
> That's an entire different view than what I've had so far (since so far I've
> never used those new "PFM"-style connections. What does it even mean?
> "Printing with Manual Formatting"? ;))

PMF = Pointer to Member Function

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[Constantin Makshin]

Another thing I personally don't like in the new connection syntax is
that it forces signals to be public, making it possible to do all type
of wonders by faking/simulating events on behalf of other objects.

For example:
QLineEdit* edit = new QLineEdit("foo");
// ...
edit->textChanged("bar");

On 03/16/2016 08:24 PM, John Weeks wrote:
> Nobody's mentioned the fact that an overridden virtual slot requires an 
> absolutely horrid cast in order to use the new PMF syntax.
> 
> -John Weeks



signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Somers]

Op 16/03/2016 om 16:12 schreef Michael Sué:

Hi,


is there a reason to have "public slots:" anymore?

If you build dialogs in Qt Designer,

I do.

you will like the function "connectSlotsByName" - called in the generated ui 
code - to work properly i.e. connect correctly just by the names you give your objects 
and slots.
I don't. Way too much magic by my taste, and it requires naming methods 
after what triggers the method instead of what the method does, which 
IMnsHO is bad practise. So it's near the top of mis-features I would 
like to have removed from Qt, or at least be made optional and explicit 
instead of default and implicit.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest