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

List:       kde-panel-devel
Subject:    Re: [Panel-devel] Scripted DataEngines
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-11-29 15:58:06
Message-ID: 200711290858.07291.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 29 November 2007, Petri Damstén wrote:
> I know that this was discussed earlier and Aaron don't like it. I know I'm

i have a few issues with teh idea, yes. i really don't want to have to deal 
with a mess of engines written in N different languages, nor do i want to 
have N+1 entry points to the engine system. i'd like to *encourage* people to 
write the engines in c++ so that we don't get these huge memory consuming 
beasts that do things slowly. we're not talking about UI here, but actual 
mechanics; it's akin to writing underlying libraries in higher level 
languages: you can but you pay a penalty.

> hardheaded and do things my own way but please at least consider this...

;)

> This patch adds support for making script dataEngines. I tried to change

*if* we are going to do this, it won't be until 4.1. and *if* we do this, i'd 
really prefer to see this done as we do with Applets:

when an applet is discovered via the kservice query, we check 
X-Plasma-Language. we then query for a Plasma/ScriptEngine plugin and load a 
ScriptEngine. we pass it the Applet* and the engine provides the glue.

this has a number of benefits over coding in the engine with X-EngineName: the 
writer only needs to know the language they are writing in, not the plugin 
that supports it; it allows us to swap ScriptEngines around for the same 
language with no changes to the scripts ...

additionally, *if* we do this, i'd like to see ScriptEngine extended to 
support this. right now ScriptEngine is pretty Applet-centric. but we will 
likely end up supporting scripted runners as well, and i'd really, really 
like to avoid having N*Y plugins where Y are the types (applets, runners, 
engine) and N are the languages. much more sensible, to me, would be to have 
one class that handles all the scripting needs for a given language. then one 
person can sit down and write one plugin; this should also keep code quality 
consistent and encourage people to work together.

-- 
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

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


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