Modularization and other languages' bindings (was: The Future of our Frameworks)

[Richard Dale]

On Monday, June 06, 2011 08:05:41 PM Luca Beltrame wrote:
> In data Monday 06 June 2011 19:26:38, Sebastian Kügler ha scritto:
> 
> (I took the liberty of adding kde-bindings to the CC of tihs specific
> topic)
> 
> > We want to make it possible to use our frameworks in Qt projects without
> 
> > significant additional dependencies. This means:
> Reading around the plans and this mails, I'd like to ask if bindings for
> interpreted languages (aside ECMAScript, which has a more or less official
> blessing thanks to QtScript and friends), were put into the equation.
I wouldn't say that QtScript has official blessing from Nokia Framworks, in the 
sense that there is a language bindings project which wraps both the Qt and 
KDE apis for QtScript programming. Obviously QtScript and QML and both first 
class citizens in the Qt libraries, but that doesn't mean there are any 
language bindings similar to PyQt, PySide, QtRuby etc for them.

There was a project by Kent Hansen to wrap the Qt apis, which was very large 
in terms of memory usage and I'm not sure if it is currently maintained. I 
don't know if anyone ever tried to extend it to cover the KDE apis.

I started another QtScript bindings project called 'JSmoke' which is currently 
stalled because of technical problems with QtScript which got even worse 
moving from Qt 4.5 to 4.6. That did cover both the Qt and KDE apis, and I 
really should try and see if it could be made viable for Qt 4.7.

> The reason is simple: those too contribute to lowering the barrier of entry
> for developers, especially the audience that has not a C++ programming
> background. If things are adjusted (without breaking things), it would be a
> perfect opportunity to involve the bindings people in the process.
The Qt and KDE apis are mainly quite well designed from the point of view of 
bindings developers. 

Things like smart pointers in the public apis (as opposed to in the d-
pointers) are a bad idea (cf KConfig)

Overloading on 'const-ness' is a bad idea for bindings (cf QDBusArgument and 
KSharedConfig). 

References to primitive types that are expected to last longer than a method 
call are a bad idea (cf KConfigSkeleton).

But really a large proportion of the apis can be wrapped pretty automatically.

> > * The impact for existing apps will be minimal
> 
> Again, this is also a perfect opportunity to get the bindings team on
> board, to ensure that the changes will not maim the bindings themselves.
> 
> Notice that this is not a criticism of what's has been done so far: on the
> contrary, I think the effort is sorely needed. I would just like to point
> out the existence of these realities (bindings) that albeit small,
> contribute their little to the use of KDE.
I am personally all in favour of the current efforts in making the the kde libs 
more modular, and allowing people to use a simpler subset if they want. That 
helps with both targeting at different devices, and it also helps with the 
learning curve if someone just wants to do a Plasma based widget and only 
wants to learn about the minimum subset of KDE api calls that they need to do 
that.

-- Richard