[Kommander-devel] Kommander in KOffice

[Sebastian Sauer]

Hi dear devel,

to be able to continue the talk started at http://dot.kde.org/1154372541/ 
without the need to recheck the article each time, let's move it to here 
where I am subscribed too now :)

So, Kross (those scripting framework I wrote within last 2 years) reuses the 
great SecureGHNS-functionality developed by the Quanta-Team and as I sayed 
already in the past ( http://dot.kde.org/1152490640/ ) I am very interessted 
to connect Kross with Kommander. 

So, I wrote at the "News from KDE Web Dev" as comment;
[QUOTE]
btw, e.g. KOffice has it's hot new stuff scripts up at 
http://www.kde-files.org/index.php
[/QUOTE]

While Eric replied;
[QUOTE]
Since you bring it up, and congrats BTW it looks great, it would be nice to be 
able to easily run Kommander dialogs from within KOffice applications. I use 
them regularly from within Quanta because it can call stdout. Then it picks 
up the pid of the calling program (Quanta) and enables me to pass data and 
control things with DCOP. In fact using Kommander dialogs with Quanta's 
scripting facility is one of the big reasons to want to share data with 
KNewStuff. It's the only way we can possibly cover our diverse user demand 
with our limited resources.
 
Am I missing how enabling this could be done easily in KOffice?
[/QUOTE] 

I agree there re easy run Kommander dialogs+scripts from within KOffice. 
Currently it's already possible since both supported scripting backends 
(python and ruby, maybe jambi will follow :) provide full transparent 
shell-access. So, it's not that difficult to call kmdr-editor or 
kmdr-executor from within a script and just use it :) Also DCOP is fully 
supported as  KSpread's "Script Editor" script-package demonstrates. It's for 
sure not that optimal to call from a native app a script that does call 
another native app to be able to script. But well, at least it's damn 
flexible (as in no dependency, easy manipulation of e.g. the passed 
arguments, etc.) and taken into account that dcop/dbus is not about 
performance anyway...

Where Kommander beats any other solution is the editor. It's still much more 
easy to use a GUI to click together whats needed rather then to start 
learning a scripting-language, hack the code in and test if it really does 
what it should do. So, myself would see Kommander more as a "Macro 
Environment with scripting skills" rather then as a pure "Scripting 
Environment". I would differ between them even if they are internaly doing 
very similar things to solve a task.

It was quit interessting to read the "Kommander's future" threads 
(http://momo.creolmail.org/pipermail/kommander-devel/2006-April/000777.html 
and http://momo.creolmail.org/pipermail/kommander-devel/2006-July/000782.html 
and 
http://momo.creolmail.org/pipermail/kommander-devel/2006-July/000793.html).

So, Kommander should be rewritten? Uhm, that sounds like a lot of work :-/ 
Anyway, if that's the case, I hope the bash won't be used again cause there 
is just no reason for it imho since nearly all scripting languages provide 
that functionality + much more like bunches of external modules, 
Qt/KDE-bindings, x-platform, etc. So, just reuse Ruby/QtRuby, Python/PyQt, 
kjs/kjsembed, Java/QtJambi, .... btw, all of them should come with bindings 
for dbus (iirc geiseri has it on his TODO for kjsembed and QtJambi final will 
have support too since it's based on >=QT4.2 which has dbus-bindings included 
while all other listened language already provide it today).

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org