Fwd: A help with JS (or maybe also Python) plasmoid

[Aaron J. Seigo]

On Tuesday 24 June 2008, Richard Dale wrote:
> 2008/6/24 Aaron J. Seigo <aseigo at kde.org>:
> > which is completely plausible; the two aren't actually linked in any way.
> > we
> > use packages for other things as well, e.g. themes.
>
> Yes, I can write a Ruby plugin type that would load pretending to be a C++
> plugin and then load the ruby code using the plasma packaging api. It's

or you could just use AppletScript.

> just  that it wouldn't be built into Plasma like the ScriptEngine/Package
> loading is. I think that is the best solution for KDE 4.1, and what I will
> try to actually implement.

and then how does AppletScript improve in the manner you say it should?

> > makes sense. in which case C# just becomes Another Language which
> > libplasma is
> > unaware of. this means less integration and no out of the box magic.
>
> Umm, the problem is that the current ScriptEngine api doesn't offer 'out of
> the box' magic apart from the packaging mechanism.

it does from the perspective of libplasma.

> > > so on - until we start iterating with something and get community
> >
> > feedback.
> >
> > agreed; but what's actually *ready*?
>
> Well nobody is working on improving the script engine api, it has stayed
> unchanged for over 2 months.

lots of classes haven't changed in 2 months. this one probably should, of 
course. i've got two pending requests from people actually using it (Google). 
so maybe that's part of the problem: the script binding people scratching 
their heads trying to decide how to approach the problem versus just diving 
in. because when people just dive it, things get done.

> I did ask about the method to invoke a config
> dialog a while ago, saying that the ScriptEngine api didn't allow you to
> access a KConfig instance to save the api details.

you mean like showConfigurationInterface() and applet->config()? i added it 
pretty much right when it was asked for. i received requests for two more API 
additions in the last week which i hope to get to sometime today.

> Of course you can just
> access the underlying applet to do that, but would that be following the
> script engine api?

yes, of course.

> Or are you just supposed to go via the provided methods
> and wait for more methods to be added in the future.

i don't see what's missing.

> >From applet.cpp:

> Why does this code suddenly lurch off into calling
> showConfigurationInterface(); if the scripting interface is being used? If

so that packages can provide a configXML and a .ui.

> scripting api to see a hash table of the config options if it doesn't have
> all the KConfigSkeleton classes wrapped. I we add KConfig specific calls to
> the ScriptEngine api you said last time I asked that it might mean it
> wasn't general enough to cater for non-Qt/KDE widgets such as dashboard. So

great, so reimplement AppletScript::showConfigurationInterface()

> The point I am making is that nobody is using this code and it isn't
> receiving any developer/user feedback like the rest of Plasma is, and
> points like this aren't being addressed.

well, the point you made is that the current API isn't actually understood. 
but i agree that it would be best to get people using it. unfortunately, right 
now the scripting efforts are nascent (manpower issues?) and when they do 
happen it's often spent in the "but that isn't how i *expect* it to be" mode.

it would be awesome to see someone actually just try and use ScriptEngine and 
make things work.

you know, like Google has done for Gadgets or we did for MacOS widgets or for 
Plasma WebKit widgets or for ECMA Script widgets or ... it's possible.

> > > change. All I know is that the current group are all 100% 'ninja' to
> > > use Aaron's terminology and would expect to be able to use the full C++
> > > api.
> >
> > So
> >
> > and we'll never get the other 98% of people unless we adjust ourselves
> > from catering to those people.
>
> Well, that's your theory, and I have expectations based on understanding
> the current Ruby programmer user base. Until we have practical experience
> and have actually expanded the user base by 100x I don't think it is
> possible to argue one way or the other.

honestly, my arguing energy limit has been reached for the day. =) you can 
think whatever you want, this is what i'm *asserting* from the perspective of 
plasma.

> > manner of "wrap an API, it's what we want!" versus "define an API, it's
> > what is
> > manageable and increases the audience"
>
> I'm afraid it the purpose and advantage is lost because we have no
> practical experience.

then help us find out.

> A good example
> is AppleScript with all those wonderful english-like constructs, which is
> actually pretty end-user hostile in practice as far as I know. Apple
> currently have a visual development tool at present for end users ,and
> maybe the best answer for Plasma would be to have something like that.

yes, lots of examples of failure in every industry/endeavor.

> Until we start trying things out, make mistakes and getting user feedback,
> I regard talk about increasing the audience as just talk.

i'm trying to try things out. instead i'm discussing yet again whether we 
should try the theory (ScriptApplet) or not. then again, Google didn't bother 
and has just Done It(tm) and are generally happy with it. go figure.

how about we just try it and find 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/20080624/9073eff6/attachment-0001.pgp