On 2/19/08, Aaron J. Seigo <aseigo@xxxxxxx> wrote:
> 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
> 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.
Yes, I agree that is very important, and probably much more important
than wrapping the complete Plasma C++ api in other languages. However,
I still feel it is a good idea to have both and will carry on working
on the Ruby and C# plasma bindings for KDE 4.1.
> 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.
That's the bit a don't understand ('misunderstand' as you say above
would be the wrong description because I genuinely don't know how that
> 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.
My specific objection is to put all the scripts in a single directory
under kde4/share/apps/plasma-script. That was how it was when I was
writing the ruby clock example a few months ago. Maybe that has
changed in which case ignore this comment. I think they should go
under kde4/share/apps/<applet name> for exactly the reasons you give
> * 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
> 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.
I was only talking about how a ruby extension inside a KDE plugin
should be started up. Whether the Ruby extension is for the complete
C++ api, or for a simple consumer oriented api I think we should use
the same code.
When a Ruby extension starts it can do api specific initialization. So
rather than KDE calling the C++ plugin api, and then some scripting
specific initialization C++ code which in turn then loads a python,
plugin type for each of these languages. Then put them in kdelibs
alongside the C++ versions perhaps.
Kde-bindings mailing list