<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Jul 25, 2008 at 7:46 AM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On 25.07.08 00:19:01, Aleix wrote:<br>
> Hi kdevelopers,<br>
><br>
> I know it is a discussion that has raised sometimes on the IRC and on the<br>
> hackaton but it is something important enough to be discussed here.<br>
><br>
> As you might know, I'm working on the KDevPlatform Kross support and, for<br>
> Kross it is necessary that an Object, to be recognized, inherits a QObject<br>
> to retrieve the methods it has.<br>
><br>
> When I have a non-QObject class, I have 2 alternatives if I want it to be<br>
> called from a script:<br>
><br>
> make it a QObject (as I did in the patch attatched)<br>
> -or-<br>
> make a wrapper as I did in kross/projectitemadaptors.h<br>
><br>
> I think it is much better to get it from the QObject because we don't<br>
> duplicate any code but I also understand that in cases where it is just<br>
> heavy to use a QObject so...<br>
><br>
> Note: the attatched patch is just an example of how things change when I<br>
> make it QObject, I don't mean it is the only cases I need that.<br>
<br>
</div></div>I'd like to add to this that there's no technical reason in this<br>
particular case to not use QObject. (i.e. these classes aren't created<br>
that often that the slight overhead of QObject has an impact)<br>
<br>
However I don't like to be punished when writing C++ code, "just"<br>
because Kross can't work with ordinary classes (and yes I do understand<br>
the technical reasons why that is so). Apart from the fact that its not<br>
proper design as these classes usually just don't need to be QObject<br>
classes and thus shouldn't be.<br>
<br>
As I already said to Aleix on IRC, IMHO we need to get bindings for the<br>
popular languages for kdevplatform - fast. Now that persistent DUChain<br>
has landed and the other parts only get smaller changes I think its the<br>
right time to ask our bindings developers to provide the bindings. </blockquote><div>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.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">IIRC<br>
the bindings-meeting produced a bridge between kross and ruby-binding<br>
objects, so obviously its technically possible to work with bindings for<br>
libraries where QObject shouldn't be introduced.</blockquote><div>The Kross/QtRuby bridge only works for QObject and QWidget based classes.<br><br>-- Richard<br><br></div></div><br></div>