[Kde-bindings] branches/work/kdebindings-smoke2/csharp

[Richard Dale]

On Monday 18 February 2008 13:53:13 Arno Rehn wrote:
> Am Dienstag 12 Februar 2008 19:14:14 schrieb Richard Dale:
> > On Tuesday 12 February 2008 17:46:53 Arno Rehn wrote:
> > > Am Donnerstag 07 Februar 2008 00:45:29 schrieb Richard Dale:
> > > > 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
> > > > > cross- desktop
> > > > > storage service for KDE PIM data. So it's not meant to be limited
> > > > > to KDE.
> > > > > APIs for other environments or other programming languages than C++
> > > > >   are very
> > > > > welcome."
> > > > >
> > > > > 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 Kimono working). They are the two most important apis to
> > > > start with. 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.
> > > >
> > > > 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 exception 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.
> > >
> > > I would like to try that but I couldn't figure out how to run plasma
> > > applets that aren't in the form of a shared library. How do you add a
> > > ruby or C# plasma applet?
> >
> > I will need to be a dynamically loaded lib - see
> > korundum/src/krubypluginfactory.cpp - we'll need a similar
> > kcsharppluginfactory.cpp to start C# plasma applets. It gets the actual
> > name of the ruby (or C#) code to run from the keyword arg string passed
> > to KRubyPluginFactory::create().
>
> Yes, that's clear. But how do you then actually load the plasma applet?
> So there's krubypluginfactory.so and e.g. plasma_clock.rb. And then?
It's driven by the .desktop file:

[Desktop Entry]
Encoding=UTF-8
Name=Ruby Analog Clock
Name[xx]=xxRuby Analog Clockxx
Comment=An SVG themable clock
Comment[xx]=xxAn SVG themable clockxx
Icon=chronometer
Type=Service
ServiceTypes=Plasma/Applet

X-KDE-Library=krubypluginfactory
X-KDE-PluginKeyword=plasma-script/clock.rb

X-KDE-PluginInfo-Author=The Plasma Team
X-KDE-PluginInfo-Email=panel-devel at kde.org
X-KDE-PluginInfo-Name=ruby-clock
X-KDE-PluginInfo-Version=pre0.1
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Date and Time
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true

The keyword option gives the name of the file to load, ie 
plasma-script/clock.rb. I assume for Kimono we would have 
plasma-script/clock.dll and that would be loaded via a suitable C function 
from the Mono runtime.

> There is Plasma::ScriptEngine and Plasma::AppletScript to implement
> scripting languages, but the API seems to be far from complete.
Yes I've never quite understood why they are needed, or how the scripting apis 
are supposed to work without needing to wrap much of the Qt and KDE apis as 
well as the Plasma api. Someone is working on Plasma applets for Ruby and for 
Python with Kross, but I don't know what is involved.

I think Plasma is just another KDE plugin api, and we should do all the 
plugins in the same way - I don't see any need to special case it - unless 
I've misunderstood something.

-- Richard