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

[Sebastian Sauer]

ups, in that case my quoting was missleading, second try;

On Monday 18 February 2008, Sebastian Sauer wrote:
> Richard Dale wrote:
> >> > 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.

there are atm multiple problems that seem to prevent to have this working.

1. in applet.cpp#132 the line;

QString path = KStandardDirs::locate("appdata","plasmoids/" +
appletDescription.pluginName() + '/');

KStandardDirs::locate does work on files and not on directories. So, it
will not find the actual path the *.rb got installed to.

2. the package-handling is imho overdesigned. That are the files in
workspace/libs/plasma/package* that expect to have a special structure
of "plasmoids" aka scripts. So, it's not enough any longer to have only a
*.desktop and a *.rb file to have this working :-/

> > 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.

Does it work for you the way you described above? I ask, cause your solution 
really looks more clear.

I also did some intensive performance-testing at the older codebase and did 
note, that it's a huge performance-problem to just redirect the paint-event 
to a script. So, probably not that important yet, but something to 
investigate for the future. I guess the initial intention to introduce 
Plasma::ScriptEngine and Plasma::AppletScript was to address that though it 
doesn't and really looks unfinished yet imho.