[Kde-games-devel] KMahjongg frameworks branch

[Ian Wadham]

Hi Frederik,

On 19/11/2015, at 12:11 AM, Frederik Schwarzer wrote:
> Am Mittwoch, 18. November 2015, 16:46:24 schrieb Ian Wadham:
>> Hi Frederik,
>> 
>> On 18/11/2015, at 10:13 AM, Ian Wadham wrote:
>> Is there any real need to change this syntax? Apparently the old
>> syntax is supported by Qt5.
> 
> KMahjongg was ported to the new syntax, so I did not want to have both 
> versions mixed in one code base.
> 
>> Also I am worried that, in old code
>> such as most KDE Games, signals with parameters might go wrong and
>> automatic disconnects might fail when an object is destroyed.
> 
> Hmm, are there known problems?

Not that I know of.  What worries me is that the preview blog about the new
syntax  (https://wiki.qt.io/New_Signal_Slot_Syntax) had a comment about
disconnection not being automatic when you delete a connected object.

The old style was failsafe and failsoft.  If one object or the other was deleted,
disconnection was automatic.  Either the receiver would no longer receive
the signals or the sender would be sending them into thin air.  I am worried
that, if some game is changed to the new syntax and the existing code does
not programmatically disconnect, there could be a crash situation when a
signal is sent, as when trying to reference a method in a deleted object.

I hope that is not the case...

> I just assumed, that whatever parameter 
> combination was possible before would be caught by the new syntax 
> automatically. It was possible for the sender to have more parameters 
> than the receiver but the receiver could obly get the parameters in 
> the same order. Is this not implicitly working with the new syntax?

I hope so, but I did not see examples of new-syntax signals with parameter
usage in the doco I have read.  I saw some mention of "automatic" type-
conversion.  I hope that would not have adverse effects on old KDE Games
code that were not programmed to expect it.

> To be honest, I do not know what happens with connects from or to 
> objects, if the object is destroyed with neither old nor new syntax, 
> so I cannot comment on that unless I get to read something more in 
> that direction.

I have found failures in signal and slot programming in games to be
tricky to debug.  That is why I would have left the syntax as is, but
this is your show, Frederik, not mine… :-)

As I said, I hope I am wrong… but keep your eyes open… :-)

Cheers, Ian W.