[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdelibs/kjsembed
From:       ian reinhart geiser <geiseri () yahoo ! com>
Date:       2006-09-28 11:37:04
Message-ID: 200609280737.05347.geiseri () yahoo ! com
[Download RAW message or body]

On Wednesday 27 September 2006 16:18, Harri Porten wrote:
> Hello Matt,
>
> On Wed, 27 Sep 2006, Matt Broadstone wrote:
> > SVN commit 589205 by mbroadst:
> >
> > OK forget this until I talk to alex...
>
> [...]
>
> > -#!/usr/bin/env kjs
> > +#!/usr/bin/env kjscmd
>
> I might be a bit late with this but I just wanted to mention that I
> was about to add a "kjs" command line client as well. Nothing
> competing with kjsembed but a very thin, interactive client very
> much like the testkjs test program.
>
> By default it will just know about standard JS API but by extending
> it with an "import" statement additional modules can be pulled in.
> Now, I've implemented just a few of these modules and they are
> nothing like what kjsembed offers. But maybe we can come up with a
> plug-in architecture that has a small client that can pull in all
> kinds of extensions?
This is exactly the direction Matt and I are talking about now.  
Basically we want the QCoreApplication version by default, since it 
has an insanely small start up time, and then as scripters add 
features we use K and QApplications respectively.

I think the goal that Matt and I talked about short term was to make 
all non-core Qt and KDE types plugins, so that we don't need them 
linked in by default.  I am not sure what the progress is on this 
though.  I think it was pending autobinder becoming more complete.

Cheers
	-ian reinhart geiser

[prev in list] [next in list] [prev in thread] [next in thread]