<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">Yes, this is what I meant, connecting to the destroyed() signal so that actions analogous to the actions now taken in SmokeBinding::deleted are performed.<br>About the argument names, it isn't that big a deal for me, even more so as I have a patch for the other way too, save for string interning. It's just that we have a working solution for this, unlike Qt 5 or the above mentioned connection to destroyed(), etc., so in my opinion this should have the least priority.<br><div><span>You haven't mentioned anything about that small document about how bindings should change for the new SMOKE, do you believe it'd be useful?<br></span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div
dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Arno Rehn <arno@arnorehn.de><br> <b><span style="font-weight: bold;">To:</span></b> kde-bindings@kde.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, September 8, 2012 10:39 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Kde-bindings] SMOKEv4 proposals<br> </font> </div> <br>
On 08/09/12 20:24, Dimitar Dobrev wrote:<br>> (4) I can't say I completely understand this feature but if this<br>> singleton is the better solution, i.e. it'd gather all these<br>> dispersed SmokeClass and etc. types, why should it be optional? Why<br>> not make it the only option?<br>Because I want to keep compatibility with C. So if you want to interface<br>with Smoke without using C++, you are free to do so, but you'll have to<br>do the low-level stuff yourself (assemblygen is doing that, for example).<br><br>> (5) I don't think the difference is that large but as taking the<br>> argument names from files performs better after all and it's already<br>> done and works, why not simply leave it as is?<br>It's simply not as nice and clean :)<br><br>> (6) How about including that mechanism (either in SMOKE or as an<br>> addition to SMOKE) that sends notifications when any Qt object is<br>> destroyed, not just SMOKE Qt objects
as it is now?<br>I guess you mean connecting to QObject's destroyed() signal. Yes, I plan<br>to add that functionality in one way or another to the high-level API.<br><br>-- <br>Arno Rehn<br>_______________________________________________<br>Kde-bindings mailing list<br><a ymailto="mailto:Kde-bindings@kde.org" href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/kde-bindings" target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br><br><br> </div> </div> </div></body></html>