[Kde-bindings] branches/work/kdebindings-smoke2/csharp

[Aaron J. Seigo]

On Tuesday 19 February 2008, Richard Dale wrote:
> On 2/19/08, Aaron J. Seigo <aseigo at kde.org> wrote:
> > for HTML, we will be wrapping QtWebKit up nicely into a little Widget
> > (all the hard work is already done in Qt 4.4) that will make it downright
> > trivial to pass it into a script and let the script do cool things with
> > it (e.g. the canvas2d api) without having to write shite loads of webkit
> > specific bindings.
>
> Yes, I guess the issue is whether or not html/css/javascript as used
> in Mac OS X widgets, is consumer friendly enough. Or whether a
> 'simplified Qt/KDE' would be better,

it's not either/or in our case. we are able to experiment freely, and the 
webkit api should be available as part of the 'simplified qt/kde'

> or a visual tool for the UI better still. 

i see this as an eventual must-have that will just take us over the top to a 
new group of people. they are a bit of a different demographic altogether, i 
think.

> > > My specific objection is to put all the scripts in a single directory
> > > under kde4/share/apps/plasma-script. That was how it was when I was
> > > writing the ruby clock example a few months ago. Maybe that has
> > > changed in which case ignore this comment. I think they should go
> > > under kde4/share/apps/<applet name> for exactly the reasons you give
> > > above.
> >
> > each applet gets its own directory. that's the entire point of packages.
>
> OK, if you've got rid of the plasma-script dir that's great.

well, actually we never had one ... since working script support went into 
libplasma, we've always put them in their dirs.

> > perhaps you can suggest a way to accomplish the above that doesn't
> > involve a C++ shim between Applet, DataEngine, AbstractRunner, etc.
>
> Yes, you can't. The only thing I'm talking about is the way that shim
> code is invoked - I think it should be from each language specific
> extension, after the extension has started. And not have special
> plugin api loading code for each plugin api and each language,
> including Plasma. Just have a way of starting each possible
> scripting/binding language, and let the extension code call back.

i'm not sure if we're talking about the same thing here.

i'm talking about the API that faces libplasma classes such as Applet.

i *think* you're talking about how to load the scripting plugins; or rather, 
how the scripting plugins bootstrap themselves (and the scripting 
environment) into plasma.

ScriptEngine is almost completely about the former and not about the latter at 
all (other than locating the lib on disk using KPluginLoader). now, if you 
have some special sauce that lets ruby scripts be loaded directly into a c++ 
app, then i'd suggest that goes into layers below plasma such as 
KPluginLoader or whatever; but libplasma itself will *still* want an API it 
can use and rely on as a go between for Applet, DataEngine and 
AbstractRunner.

but maybe i'm just not understanding what your suggesting at all. can you give 
me some example in code / pseudo-code that illustrate what you are wanting to 
do?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080219/965355e1/attachment.pgp