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

List:       kwrite-devel
Subject:    Re: KDE 4 + plans
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2008-01-15 15:46:13
Message-ID: 200801151646.14242.mail () dipe ! org
[Download RAW message or body]

On Tuesday 15 January 2008, Christoph Cullmann wrote:
> Hi,
> 
> sorry for replying bit out of order. I have question :) Have read the
> howtos a bit, I am still curious: How it is possible with Kross to first
> evaluate a script and later call functions out of it with parameters (and
> retrieve the return values). Could you point me to an example?

Well, once a script got executed (triggered), it stays loaded till finalized 
and waits for beeing called.
That means, first you fill such a Kross::Action, then it's triggered and later 
at any stage either callFunction() can be used to call a script function with 
any parameter (QVariantList) + handle the returnvalue (QVariant).
Guess I just realized that there is really no sample at the tutorials how to 
use that. Uh, sorry. I was beliving there is :-/ Well, there seems to be at 
least a small sample that shows how callFunction is used within 
http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/kross/html/classKross_1_1Action.html


The alternate way (and seems so far most users did prefer that way) would be 
to use here signals+slots like shown at 
http://techbase.kde.org/index.php?title=Development/Tutorials/Kross/Connecting_Signals_and_slots_in_Kross#Autoconnecting_Signals_and_Slots
 The "trick" here is, that Kross will automaticly connect each signal the 
QObject has to a matching scripting function. At the C++ side all what is 
needed is then to emit the signal and behind the scene the arguments will be 
translated and a possible defined scripting function got called.

A good example here is SuperKaramba which uses the signal+slot way. All it 
defines is the rather huge class 
http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/src/karambainterface.h?view=markup
 The signals are transparent mapped to scripting functions (e.g. 
http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/template.py?view=markup \
 and 
http://websvn.kde.org/trunk/KDE/kdeutils/superkaramba/examples/template.js?view=markup \
)  while the slots are then callable from within the script.
The reason why everything is within one class is backward-compatibility. It's 
for sure also not a problem to have multiple classes and pass around QObject 
instances, etc. like it's done e.g. at KSpread.

Re performance and optimization; for me it's also very important to note, that 
we did put quit a lot of time into performance (here Cyrille from Krita-fame 
spend a lot of time to tweak Ruby for Krita while myself did the same for 
Python). JavaScript (as in Kjs+KjsEmbed) is just slow by design and there is 
nothing somebody can do about this - it's around 20x slower then Ruby). Also 
Python was never designed with speed in mind, though we got it to be "only" 2 
times slower then Ruby (which just has an amazing good internal design). Also 
wirr from SuperKaramba-fame and myself did spend quit a lot of time to fix 
all mem-leaks (in python and ruby - no idea there about 
JavaScript/Kjs/KjsEmbed since so far just no user did show up in the SK-case 
who likes to write JS-Karambas) cause SK-scripts may run a very long time 
embedded in the desktop.
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel


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