From kwrite-devel Tue Jan 15 15:46:13 2008 From: Sebastian Sauer Date: Tue, 15 Jan 2008 15:46:13 +0000 To: kwrite-devel Subject: Re: KDE 4 + plans Message-Id: <200801151646.14242.mail () dipe ! org> X-MARC-Message: https://marc.info/?l=kwrite-devel&m=120046354006685 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