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

[Aaron J. Seigo]

On Monday 18 February 2008, Richard Dale wrote:
> On Monday 18 February 2008 22:13:38 Sebastian Sauer wrote:
> > Richard Dale wrote:

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

this is a fundamental misunderstanding of how Plasmoid scripting should really 
happen.

the goal is NOT to provide a complete set of bindings for scripts to go crazy 
with. why? because that would make it nearly impossible for *average* people 
to write things. hell, we may as well ask them to go off and learn a "real" 
language at that point.

no, the goal is provide a very well contained and *small* API that is not a 
1:1 mapping to all the power and glory that is Qt and C++ and the rest of the 
world, but a simplified API. ever wonder why i spent so much time doing 
DataEngine which is simply a shim between plasma components and *real* data 
models? yeah, because *real* data models are too varied and too complex; they 
would require tons of bindings all over the place and tons of explanation to 
the plasmoid writer.

instead we have one little set of api (essentially 2 functions, from a 
script's perspective) that opens the whole world of data to them.

while your perspective is correct from a general language bindings 
perspective, one needs to start thinking in terms of consumer development 
environment (not programmer developer environment) and the general goals of 
plasma to get this right in the context of plasma.

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

hm. this was working just fine as i was able to run the tiger plasmoid quite 
nicely. i'll look into it however and see what has changed and why and what 
needs fixing, if anything.

> > 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 :-/
>
> Well this just seems wrong to me. The .desktop file should define the type
> of the service and how to locate resources, and Plasma shouldn't be trying
> to reinvent this.

i understand how you can come to this conclusion without a full understanding 
of the issues at hand. right now i really don't have the energy to sit here 
and explain to you all the various reasons for this decision, so i'll do the 
cliff notes version:

* we need a way to provide other data besides the script file that can be 
accessed by libplasma. leaving this up to each language binder is complete 
chaos and simply will not work.

* we want to be able to provie a way to have people package up their contents 
for sharing with others easily (e.g. via a GUI) and Plasma::Package provides 
that

this goes waaaay beyond "load a script and run it". so if you have actual, 
real problems with it that impact you in actual, real ways please let us know 
(on panel-devel, not kde-bindings) and we can sort it out.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080219/cd02fe89/attachment.pgp