[Kde-bindings] SMOKEv4 proposals

Dimitar Dobrev dpldobrev at yahoo.com
Sat Sep 8 19:59:31 UTC 2012


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.
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.

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?



________________________________
 From: Arno Rehn <arno at arnorehn.de>
To: kde-bindings at kde.org 
Sent: Saturday, September 8, 2012 10:39 PM
Subject: Re: [Kde-bindings] SMOKEv4 proposals
 
On 08/09/12 20:24, Dimitar Dobrev wrote:
> (4) I can't say I completely understand this feature but if this
> singleton is the better solution, i.e. it'd gather all these
> dispersed SmokeClass and etc. types, why should it be optional? Why
> not make it the only option?
Because I want to keep compatibility with C. So if you want to interface
with Smoke without using C++, you are free to do so, but you'll have to
do the low-level stuff yourself (assemblygen is doing that, for example).

> (5) I don't think the difference is that large but as taking the
> argument names from files performs better after all and it's already
> done and works, why not simply leave it as is?
It's simply not as nice and clean :)

> (6) How about including that mechanism (either in SMOKE or as an
> addition to SMOKE) that sends notifications when any Qt object is
> destroyed, not just SMOKE Qt objects as it is now?
I guess you mean connecting to QObject's destroyed() signal. Yes, I plan
to add that functionality in one way or another to the high-level API.

-- 
Arno Rehn
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20120908/a500accc/attachment-0001.html>


More information about the Kde-bindings mailing list