Today I may have stumbled upon why the people working on scripting for Plasma tend not to grok at first the point and purpose of ScriptEngines or any of the other mechanisms we have put in place for this:
In most cases, the API is defined by the host and the language binding is just a mapping of that API into the runtime environment the code will be run in.
With Plasma it's really the other way around. The language support (not necessarily bindings!) define the API while libplasma simply provides the canvas and management of the components. The language support defines the API, which could be a 1:1 mapping to the libplasma API but really doesn't need to be.
So the language people have been looking at Plasma asking, "So... how do I bind to this API?" and see ScriptEngine which is totally unsuited for that and scratching their head. Meanwhile, I get to explain for the Nth time (where N == number of languages people are working on ;), probably rather clumsily, that binding isn't the point of those classes. =)
Now that I finally understand this difference in perspective, perhaps I'll be able to articulate it more accurately in future.
Thursday, May 08, 2008
Subscribe to:
Post Comments (Atom)
8 comments:
Hmmm, perhaps you can articulate it a little better when you're feeling better? The third paragraph looks like an explanation of some sort but it doesn't quite work for me.
the idea of ScriptEngine is that it provides the glue between libplasma and whatever API lays on the other side.
remember that we support things as wildly different as HTML/CSS, Ruby, Pything, ECMA Script. ok, Ruby and Python aren't all that different, but there are pretty well three categories there.
so we don't define the API for these add ons in ScriptEngine.
instead, we provide facilities for widgets in libplasma including packaging, configuration, svg painting classes, the canvas that gets painted on, etc, etc.
but it is up to the ScriptEngine itself to decide which of those facilities to use and how to make them available to the widget/engine/runner.
thus libplasma does not actually define the scripting API at all. while one can just do a 1:1 mapping, that's not only not required it's simply not possible with some of the supported widget systems. this approach allows to provide nice management for non-compiled components while letting these APIs be, quite literally, first class citizens.
this really runs rather counter to how scripting usually is implemented apparently, where the API is defined and bindings of that API are put into the runtime environment.
going at it expecting there to be some 1:1 bindings style set up leads to all sorts of confusion when one attempt to use ScriptEngine; and if you don't use ScriptEngine you lose out on *all* the management libplasma provides for non-compiled components.
ergo: confusion.
personally i was a bit confused as to why people doing language support were having such a hard time "getting it", but after several conversations and some further rumination today, i realized that it's a difference in starting assumptions.
as for why i chose this route: as i hinted at earlier it's a requirement for the flexibility we have achieved. i don't see how we could have so easily mated mac os dashboard widgets if the assumption in the scripting support was "it will use the plasma API".
I see. Yes, I'd expect a PyPlasma thing next to PyQt & PyKDE for example ;)
I wonder if this approach would let me include a custom QGraphicsItem in an applet from e.g. Ruby
I wonder if this approach would let me include a custom QGraphicsItem in an applet from e.g. Ruby
Yes, you will be able to do that in the ScriptEngine based Plasma Korundum ruby bindings, and the api will be pretty much the same as the C++ api.
@Iuri: "if you stop breaking ABI/API compatibility each major version"
given that we haven't done more than 1 release yet and that i said 4.1 would have API changes before 4.0 was even out so that we can move to API stability in 4.2, this is an odd comment =)
"plasmoids won't follow KDE release cycle"
that doesn't resolve issues surrounding libplasma, the core desktop on top of it and similar developments.
many plasmoids are already in extragear so that they can be freer about their development cycles.
"From a user perspective, 6 month release cycles are a way to go, it's just excellent."
why, because you get an update every 6 months? consider that with that update every six months you get a product that is less than it could be.
pandering to what the consumer thinks is what they want is a bad decision when that runs counter to providing what they really want.
"so all of them would use the same kernel/libs/desktop version.
It would be MUCH EASIER for developers of small projects."
the assumption here is that everyone upgrades constantly (untrue) and that there are massive differences between them as it is. it also implies that the same set of libraries are installed and in the same locations, which also isn't true.
what you're looking for is the logical conclusion of the LSB, something that a release cycle synchronization doesn't do anything for.
"Sad that someone loses on that timing scheme,"
i'm not sure how you got onto a either/or tangent here. i'm simply saying this isn't working for plasma. period. saying it works for someone else doesn't change that fact. moreover, i'd suggest that your examples of apps not tied to a single release heartbeat being some of the best kde apps out there actually strengthens my whole point.
@Kevin: "Drop the global feature freeze"
that would make for a completely chaotic release. untenable.
"their reponsibility to make sure they have something releasable when KDE releases."
which implies having a global schedule.
"implementing a small feature in a small application wouldn't have to follow the freezes as long as it's ready in time for the release"
the problem isn't that schedules are a bad idea or that feature freeze periods are counter productive. schedules and freezes are actually quite good.
it's been my experience that a "small feature in a small app" is no less likely to go awry than most other features and so also benefits from betas and rc's; throwing these kinds of things in at the last minute would be pure chaos.
it's the duration of the schedule that isn't working here; a larger duration accommodates more projects, and a shorter duration accommodates the needs of fewer.
the choices end up something like: compromise and takes a duration that is a bit longer than some need (and likely still shorter than others might want); hobble development of apps that really need bigger windows or shorter but non-multiples of the interval; find a way to let apps develop on their own schedule and synchronize to a global release.
for the confused: it seems aaron's last two comments were actually meant for his previous post :)
Post a Comment