[Kde-bindings] Kde-bindings Digest, Vol 51, Issue 17

[Dongxu Ma]

>
> On Thursday 19 July 2007, Dongxu Ma wrote:
> > >On Wednesday 18 July 2007, Dongxu Ma wrote:
> > >> Hello Richard, CC: gents,
> > >>
> > >> Beside object bus, how do you deal with allocation of Qt/Kde object ?
> > >> First I'd like to share you my progress on my QT4 Perl binding. Due
> to
> > >> personal issues, I recently didn't pay much time on coding...
> > >> The typemap system is almost finished. You can check here (
> > >>
> http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl)
> > >> The typemap, as you know in perl, is the repos for type marshalling
> >
> > between
> >
> > >> perl and c++ plants. While the old typemap mechanism introduced by
> > >> ExtUtil.pm is somewhat out of date, it has no knowledge about
> >
> > relationship
> >
> > >> between relevant types. Say, for instance, QString and QString *.
> > >> Typemap simply treats them as un-relevant ones.
> > >> What I did in tha script is a knowledge study and relationship
> analyse
> > >> system. For above example, in case it knows QString is a QObject
> >
> > (obviously
> >
> > >> from qstring.h), it automatically knows how to marshall QString *,
> >
> > QString
> >
> > >> &, const QString, const QString * and QString const *. Furtherly
> > >> QList<QString *> is possible. It goes thru different aspects to find
> > >> type relationship ( class declaration, inheritance tree, namespace
> path,
> > >> pre-defined typemaps ).
> > >> It is powerful enough to bridge native Qt type with KDE type, custom
> >
> > type.
> >
> > >Well I think we already have this sort of thing in the Smoke libs, and
> we
> >
> > have
> >
> > >a parser written in perl with powerful abstract syntax tree utilities
> for
> > >walking round the parse tree.
> >
> > Nice. I used to have a look at Smoke, the output is quite programmatic
> look
> > (in C),
> > that is one of the primary reasons I'd like to write QTEDI, which
> presents
> > in more
> > human-readable style. While that doesn't mean Smoke is ugly, really
> depends
> > on
> > how people make use of.
> Well I don't think that being able to read the autogenerated code is all
> that
> important. Nobody is going to read 1000s of lines of yaml either. You can
> introspect the smoke lib to ask what classes and methods it has though,
> which
> is certainly useful, and something you can't do in any other language
> binding
> library as far as I know.


Point here is not only readability, but also the chance to patch at certain
point. I can also develop nice tool to query, I'd also like to have enough
place to apply patch. The opportunity is open for new maintainer too.

> >> While the bad situation I am facing is GC system. Perl uses simple
> > >> reference, while ruby makes use of mark and sleep way. On the another
> >
> > hand,
> >
> > >> generally, various cases may mess GC:
> > >> 1) GC in Qt itself: Qt maintains its internal object reference
> status;
> > >> 2) non-new method which exports an internal address,which will have
> the
> > >> same lifecycle of exporter;
> > >> 3) non-new method which returns a new heap address, which transfers
> the
> > >> ownership of that pointer to caller;
> > >> 4) non-new method which accepts a pointer and takes the ownership of
> > >> that pointer;
> > >>
> > >> Either case will leak the vm unless treating it carefully.
> > >> I'd like to hear your words on this question.
> > >
> > >The Smoke bindings have a struct like this:
> > >
> > >struct smokeqyoto_object {
> > >   bool allocated;
> > >    Smoke *smoke;
> > >   int classId;
> > >   void *ptr;
> > >};
> > >
> > >Where 'allocated' is true if the instance was created in the bindings
> > >language, and so the bindings runtime is responsible for deleting the
> C++
> > >instance on garbage collection.
> > >
> > >The bindings runtime needs to know about the various rules of object
> >
> > ownership
> >
> > >in the Qt libraries such as the QObject object tree where a parent
> 'owns'
> >
> > its
> >
> > >children and is responsible for deleting them.
> > >
> > >The QtJambi bindings have a third state, which is 'not owned by either
> c++
> >
> > or
> >
> > >the bindings language'.
> >
> > The hard point here is the handover of object relationship is really
> case
> > by case.
> > The metaobject system in Qt is mainly based on class inheritance
> hierarchy.
> > That doesn't really work for the case: the instance exports an inner
> part
> > (note
> > that such part is in-a-class, not is-a-class); while other method may
> > export a
> > component of itself, which is certainly a standard QObject, and release
> the
> > ownership of that component to caller; From my point of view, it is very
> > hard to
> > tell such two different cases automatically.
> > Another example to address one of my previous points: say, one creates a
> > new
> >
> > QObject in binding code, then QObject is owned by binding code till a
> > special
> > method is invoked, which takes that QObject as parameter and finally
> 'eats'
> > it.
> > That dedicated QObject is taken over by Qt metaobject after the call,
> > regarding
> > its lifecycle.
> > You can find such method somewhere inside Qt (sorry, I don't remember
> the
> > class
> > name but I am pretty sure it has).
> > The issue here is Qt metaobject system doesn't offer any callbacks on
> the
> > events
> > of importing/exporting a child. A message bus between Qt and bindings.
> > There is QObjectCleanupHandler, not very helpful in this paticular case.
> > Things go more complex if we start talking about non-meta classes (which
> is
> > declared without Q_OBJECT macro). This side is completely out of control
> > from
> > Qt metaobject system.
> Yes,  there is an internal method for monitoring changes in QObject
> parents
> via events. From qyoto.cpp:
>
> QInternal::registerCallback(QInternal::EventNotifyCallback,
> qyoto_event_notify);
>
> Then qyoto_event_notify() is sent events:
>
> static bool
> qyoto_event_notify(void **data)
> {
>     QEvent *event = (QEvent *) data[1];
>
>         // If a child has been given a parent then make a global ref to
> it, to
> prevent
>         // garbage collection. If a parent has been removed, then remove
> to global
> ref
>         // to the child also.
>         if (event->type() == QEvent::ChildAdded || event->type() ==
> QEvent::ChildRemoved) {
> ...


Great, I really didn't notice that! But as I said this mechanism only works
for meta-lized QObject.

> >> PS: boost python binding page also discussed similar issues. Go and
> take
> >
> > a
> >
> > >> look.
> > >
> > >What will it tell us that we don't already know, and what do you think
> is
> > >wrong with out existing approaches?
> >
> > Trust me, I am really not arguing current kde-bindings' implementation
> ;-)
> > Please don't treat me like an enermy ;D
> > I pay my enough respect to you guys behind this maillist, indeed.
> > Noticed that recently there was a post saying different words on
> > kdeveloper.org.
> > I think the author was quite friendly and really wanted to bring new
> ideas
> > in.
> > Things are always improved by questions and innovations.
> > We can keep walking on each own way but we can share our thoughts, right
> ?
> Sorry if I sounded rude. It's more that I'm not sure if you've studied the
> code for the existing Qt bindings enough. Unless you can understand what
> they
> do, and how they do it, then it will be very difficult to design something
> better. You'll probably just end up re-inventing what we already have. So
> maybe boost python have done something none of the bindings authors (ie
> the
> QtJambi, PyQt, QtRuby, PerlQt, Qyoto and PHPQt authors) have thought of.


Yes, that's probaly true. Sorry I haven't read much code of Smoke and Qt. To
be honest I dislike the look of Smoke output, which is totally C++ code.
Very hard to analyse for a new comer..
To my project, I am not sure how far it can go, try my best to make it
better.
Keep your speed too :-)

> > >Note that the subject of this thread is 'splitting up the smoke
> libraries'
> >
> > -
> >
> > >please can you start a new thread to discuss anything which isn't about
> >
> > that
> >
> > >topic?
> >
> > Sorry, that topic triggered me yesterday.
> OK, no problem - it just easier for people to follow the history of the
> discussion in the if we can keep the threads a bit self contained.
>
> -- Richard
>

-- 
cheers,
-dongxu
__END__
http://search.cpan.org/~dongxu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20070720/bc42a2bb/attachment.html>