[Panel-devel] Introducing me

[Matt Broadstone]

On 9/17/05, Eric Jardim <ericjardim at gmail.com> wrote:
> 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.
>  
For the meantime, if you'd like to work with bindings as they relate
to Plasma, we're going to use SK as a sort of playground for the
bindings used in Plasma. Plasma itself is just as too young a stage
imho to start popping bindings in. Though planning for it is
definitely very useful, if you want to dive right in and try making
bindings for applets right now (as you seem to be) then SK is where
it's at :)



>  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]
>  
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
> 
> 
>