QObjects on interfaces

[Richard Dale]

On Fri, Jul 25, 2008 at 7:46 AM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 25.07.08 00:19:01, Aleix wrote:
> > Hi kdevelopers,
> >
> > I know it is a discussion that has raised sometimes on the IRC and on the
> > hackaton but it is something important enough to be discussed here.
> >
> > As you might know, I'm working on the KDevPlatform Kross support and, for
> > Kross it is necessary that an Object, to be recognized, inherits a
> QObject
> > to retrieve the methods it has.
> >
> > When I have a non-QObject class, I have 2 alternatives if I want it to be
> > called from a script:
> >
> > make it a QObject (as I did in the patch attatched)
> > -or-
> > make a wrapper as I did in kross/projectitemadaptors.h
> >
> > I think it is much better to get it from the QObject because we don't
> > duplicate any code but I also understand that in cases where it is just
> > heavy to use a QObject so...
> >
> > Note: the attatched patch is just an example of how things change when I
> > make it QObject, I don't mean it is the only cases I need that.
>
> I'd like to add to this that there's no technical reason in this
> particular case to not use QObject. (i.e. these classes aren't created
> that often that the slight overhead of QObject has an impact)
>
> However I don't like to be punished when writing C++ code, "just"
> because Kross can't work with ordinary classes (and yes I do understand
> the technical reasons why that is so). Apart from the fact that its not
> proper design as these classes usually just don't need to be QObject
> classes and thus shouldn't be.
>
> As I already said to Aleix on IRC, IMHO we need to get bindings for the
> popular languages for kdevplatform - fast. Now that persistent DUChain
> has landed and the other parts only get smaller changes I think its the
> right time to ask our bindings developers to provide the bindings.

OK, I will try and keep the kdevplatform smoke lib and ruby extension
working and following the changes in the KDevelop headers for KDE 4.2. But
recently there has just been too much 'header churn' to make that possible.
It should be possible to create a C# extension, but the headers will need to
be more stable again to make that worthwhile. We've recently got KTextEditor
based bindings working with Ruby and C# and that is an important foundation
for the KDevelop stuff.


> IIRC
> the bindings-meeting produced a bridge between kross and ruby-binding
> objects, so obviously its technically possible to work with bindings for
> libraries where QObject shouldn't be introduced.

The Kross/QtRuby bridge only works for QObject and QWidget based classes.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080725/8ceb0909/attachment.html>