[Panel-devel] Introducing me

Eric Jardim ericjardim at gmail.com
Sat Sep 17 23:22:14 CEST 2005


2005/9/17, Aaron J. Seigo <aseigo at kde.org>:
>
> november 1 is my target for having the bindings projects (among a couple
> of
> other things) ready to start. it first requires, obviously, some plasma
> APIs
> to be at least semi-settled in.
>
i expect the process to be somewhat iterative.


Ok, between that is it possible to play with KDE4/Plasma yet? Without
messing with my KDE3 configs?

i'm particularly interested in a plasma API only set of bindings, which
> shouldn't be a problem. what you could provide that would be of quite some
> value to us in the meantime is input onto the binding plugin API and
> system
>
the idea is to have the language bindings individually loaded on demand when
> required for a given applet, which in turn requires at least one base
> class
> to use as the plugin loaded that would then allow us to feed scripts to an
> interpreter, to an executor and also provide bindings.


We could work on something like a C++ interface for all interpreters. After
that, the rest of the work is just as normal bindings. Instead, we could
think of something like auto-generation, but I have some ideas that need to
be discussed later.

I am just worried about incorporating the boost libraries as a dependency
for Plasma Python script. But it is much bet. But what if we do some static
libraries... (thinking)


i'm also very interested in the ability to thread as much of this as
> possible.
> with JS we should be able to have all the parsing done in one thread, and
> probably execute each script thereafter in their own thread. i'm still
> working on how to do the painting (off-screen painting might work though;
> or
> building SVG interfaces with Qt4.1; still working on the details)


Fine, but what kind of thread you are talking about? I mean, we can thread
in the C++ level with the QThread (or not) classes, or we can thread in
Python (which is more complicated, I think).


with python, how realistic will it be to put parsing, execution, etc in
> their
> own threads?


I know it is possible to deal with threading. But it might give me some
headaches :)

also, we need to make the language plugins API async in nature (even if it
> is
> all done synchronously behind the scenes)...


The interpreter can run on the same thread. If not, the context change must
be explict and locked. I don't like thread (don't find then useful), and if
you want to use, you must accept all it's implications. We still have
execution loops and timers :)


anyways, input from those doing language bindings is more than welcome.
>

I will try to help in what I can. Time is not my friend, you know. By now,
python-qt4 is my main goal. But it would be cool to play with Plasma and
that would be nice if I can share some of the time I spent in Qt4 to be used
in Plasma.

That's it,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050917/68ba817e/attachment.html


More information about the Panel-devel mailing list