[Panel-devel] Introducing me

[Matt Broadstone]

On 9/17/05, Eric Jardim <ericjardim at gmail.com> wrote:
> 2005/9/17, Matt Broadstone <mbroadst at gmail.com>:
> > Unfortunately the bindings that are created your (and richard's) way
> > are not what we need for Plasma. We're currently researching into
> > things like Kross, which provide swappable interpreters on runtime..
> > perhaps you'd be interested in working with that, join us in #plasma. 
> 
>  I have just read the Kross page:
> http://www.kexi-project.org/wiki/wikiview/index.php?Scripting
>  
>  and found out that it is exaclty the project that the guy of Kexi started.
> Hi had problems dealing with more than one script languagens in the same
> language.
>  
>  But it does not change the thing, if you are runnig the Python (or
> whatever) interpreter, you can still link it to the C++ app with the script,
> just have to implement the interface (that he calls Kross). So we are
> talking about the same thing. Just need to implement a simple backend.
>  
Yes this is the approach that's looking most ideal right now. Kross,
afaik, is not the interface to Kexi. The interface for Kexi is called
the "scripting core" which provides an abstract interaface to Kexi.
Kross is meant to be an api that provides something like a
ScriptManager to dynamically load an interpreter for a given language,
and then bind that language to the abstract interface.

>  Indeed, reading the page, I discovered that the Kexi guy had some deals
> with licensing. He wanted to publish Kross under LGPL and Qt is GPL, so you
> cannot. That's why Kross is so loose(not binded to the Qt lib). But KDE is
> GPL, so is Qt and python-qt4 (my bindings). So why do twice the job if we
> can have one complete solution?
>  
To make things clear, we do not need a complete set of bindings to
qt4... only what's necessary for Plasma. This is why I was looking
more closely at Kross, because it's meant to be a specialized binding.
I hope you don't interpret what I'm saying as "I don't think we should
use your work at all," I just don't think in its current form it is:
A) efficient for our somewhat special case
B) Flexible enough to support the languages we plan to support.

Ideally, we can find a solution (somewhere between your work, Kross,
Korundum etc) that automatically generates the bindings for each of
the languages we plan to support. If we were to start popping code
like yours in without thinking about the bigger picture then we end up
with different maintainers for each binding and such sorts of hairy
business..

>  Another thing he pointed is that bindings were done with SIP or SWIG, that
> have many limitations. But python-qt4 uses Boost.Python (from the Boost
> libraries) and is very powefull, and you can do bindings in the same
> language (C++) you are exposing from.
>  
>  So... now we have a point?
>  
>   [Eric Jardim]
>