[Kommander-devel] Kommander in KOffice

[Eric Laffoon]

Hi Sebastian!
Welcome to the Kommander Developer list.

On Tuesday 01 August 2006 6:42 am, Sebastian Sauer wrote:
> 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.

Ouch! Color me blushing red. How did I miss this? First of all, thanks so much 
for your kind words. Let's do it. I have to say though that I've started 
discussions with a number of KDE developers about Kommander, and it's like 
beting in the twilight zone getting the response. Maybe it's somehow 
threatening to their projects or something, but it's been like selling $10 
bills on the street corner for $5 and having everyone tell you that they 
don't understand because the barter system works great. So I'm truly 
delighted to hear from you, especially as I love KSpread and would dearly 
love to have access to use Kommander in it.
>
> 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...

There are several things that have come up in our experience. For one, we 
tried early on an experiment of making DCOP calls through the shell and 
making them with an internal interface, not through the shell. What we found 
can be demonstrated by setting widgets on a dialog when it opens with the old 
shell based DCOP calls and the new internal calls. The shell based calls mean 
you can watch the widgets flash one at a time as they update. The internal is 
instantaneous visually. We found that DCOP could process several thousand 
calls a second if it didn't go through the shell. This is why I decided that 
pulling out the MainWindow abilities of Kommander was a mistake. Sure enough 
people are building monster dialogs. Clearly people refuse to be constrained 
by our initial concepts, like the guy who created a DTEP for Povray in 
Quanta.

The other thing is that DCOP calls are generally focused on developer usage. 
We feel this is a mistake because they offer users the ability to "glue" 
applications together. We have two targets. First we want to make an enhanced 
tool for Kommander where DCOP functionality for an application can be 
registered and restructured in a tree based on user perspective. This would 
be an XML definition set for the application DCOP functions that were most 
useful. So users would have the option to browse a more user friendly DCOP 
tree if someone wrote that XML, or go to a kdcop view. Our next objective, 
assuming we could get developers to see the benefit, is to lobby them to 
consider better support for external control when they write the app. An 
ideal world has KDE setting up DBUS design standards that facilitate this so 
that the user based definition is automatically created.
>
> 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.

I agree, but the really cool thing about Kommander is that it is a scripting 
tool that is not a classic scripting tool. We don't script the GUI and that 
means it's much faster and easier to build, but we can create the XML on the 
fly with a script. The big thing is that it's very fast to display because 
it's light and lean C++, visual flaws and bugs are practically eliminated 
compared to a scripted approach, the amount of code needed is less and it can 
integrate various scripting languages.

If what you need is just a script, Kommander is not a compelling choice. If 
what you need is a script that runs top down and displays dialogs it's not as 
compelling. If what you need is to bring up a visual interface for event 
oriented manipulations it's hands down the best tool.

So I agree with you, but while I find scripting very powerful I find I often 
want to be event driven. Moreover Kommander does one more very cool thing. It 
exposes every action the opportunity to operate in a different scripting 
language. People are zealous about what they like to program in and weary of 
having to learn new syntax and commands to get a job done. Paradoxically 
because of the parallel execution of Kommander and a script we have been 
forced to add some things to logic control, but we took KSpread as a model to 
make functions in Kommander be as easy as point and click. Eventually we want 
to be able to extend this to where you could write the support in for Ruby or 
Python.

One more thing. Since Kommander also has internationalization it offers 
application developers a very cool tool. You can take a vague interface idea 
you don't work a lot with that users want, through a draft together and put 
it in the community and using KStuff have your heavy users reshape it. 
Ideally we want to create easy ways to make it compile, but then what if we 
knew users had the executor? You could release extentions any time for 
download without messing up development and through the next cycle they could 
be internationalized. Users could modify them for their best use. After six 
years of release freezes and half baked features this sounds like paradise to 
me.
>
> 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).

Kommander needs to be rewritten because the internals of the old Designer are 
frankly a mess. Also as a development tool it applies what it does 
differently from Designer. Therefore it should reflect this. It should be 
more like Quanta where you can have multiple real editor tabs for widgets and 
the window you are designing should come up to the top instead of the editor. 
It would be the opposite. It will probably be based on KDevelop. Then for the 
visual part we need to choose between doing designer over or using the visual 
tool in Kexi, which probably makes more sense. As far as the language base 
goes here's where we are on that...

Ideally we would be language neutral. If possible it just wouldn't have a 
language but would facilitate whatever one you wanted. Of course that's not 
so easy. Because of the issues concurrent processes we have a communication 
issue if your language can't speak DCOP/DBUS back to Kommander. Our solution 
is to advocate the use of an internal very simple scripting language, that 
can be written with the Function browser, to control the internal logic of 
the dialog/application. Then the operations can be scripted independently in 
any language. This would mean a Perl guy, a Python guy and a Ruby guy could 
get together and make an application. Now, if someone doesn't want to use our 
own internal scripting but prefers to control the whole thing with another 
language then all that should be required is the language they choose has 
DBUS bindings. So our internal scripting is for total scripting novices, 
dispute resolution ;-) and using languages like PHP.

In light of this we don't really need anything like PyQt or the like. After 
all Kommander can create windows and widgets and even do some things on the 
fly (with a little trickery). However this shouldn't preclude the use of 
these other tools along with Kommander. It could be crazy. One thing to keep 
in mind is that we will sacrifice that last little bit of power for 
simplicity of use and speed of design... But that's where I say "why not just 
use C++?" ;-)

Being able to create a Frankenstein monster of a program with all these tools 
does have entertainment value for me. ;-)
-- 
Eric Laffoon
Project Lead - kdewebdev module