On Feb 7, 2008, at 12:45 AM, Richard Dale wrote:
> On Tuesday 05 February 2008 13:13:56 Thomas Moenicke wrote:
>>> We could keep the old smoke-lib somewhere, but I'd really appreciate
>>> it if we
>>> could get modular smoke into KDE 4.1 and if possible even Kimono.
>> I would really like to see an Akonadi module for the new smoke by
>> default. It is on the wish list of many people and mentioned by
>> Cornelius Schumacher in the kde-pim 4.1 plans:
>> "The long-term mission of Akonadi is to provide a cross-platform
>> storage service for KDE PIM data. So it's not meant to be limited to
>> APIs for other environments or other programming languages than C++
>> are very
>> Any plans yet?
> Well I think we should plan on including Plasma and an Akonadi api
> with the
> modular Smoke for KDE 4.1 for both Ruby and C# (assuming we can get
> working). They are the two most important apis to start with.
How much work was it to derive plasma ruby from qtruby, did you
implement more special handlers?
> Once we've done
> that, autogenerating bindings for other KDE apis shouldn't be a big
> deal, and
> we can add them as we get them working.
I assume it will be _one_ binding for each language in future that can
deal with all modules on demand once the module was implemented in the
> At the moment with the Plasma bindings, if Ruby throws an exception
> it doesn't
> get caught and it then crashes Plasma. So we will need to add
> handling at the top level for both Ruby and C#. Also there is some
> kind of
> memory corruption happening in the Ruby Plasma bindings where slot and
> virtual method callbacks fail after the analogue clock plasma applet
> has been
> running for 2 mins or so. I don't know if this will affect Qyoto/
> Kimono C#
> applets until we try it out.
> -- Richard
> Kde-bindings mailing list
Kde-bindings mailing list