A while ago, it was questioned on kde-devel why was KFileReplace in the KDE WebDev package. The reasoning is that no one looking for that application specifically would think it was inside a web development package. The same holds true for Kommander. It is not really a web development tool, so it is kind of weird to have it in WebDev. Kommander has great potential. It is easy to use, and is getting even more powerful.

During the discussion, I asked whether the Kommander executor could be moved to kdelibs. That would mean that although you'd still need WebDev installed to create Kommander "scripts" (what should I call them?), these "scripts" could be run "out-of-the-box" on any machine that has KDE installed. While no one agreed with me that the move could happen already for KDE 3.4, it seems that it is actually the intention of the developers to do this, but later. Nice. Kommander is one among the incredibly powerful features of KDE few people know about (KIO-Slaves are another of those, but it seems there is discussion about how to expose them better to the users going on).

There's just one small problem in the Kommander Executor move to kdelibs: it is not a lib, as it was pointed. Yet I still think it deserves being there. IMHO, the kdelibs package should provide the basic framework needed to run any KDE application, and I believe Kommander dialogs can be counted as "simple KDE apps".

If you don't know Kommander yet, or aren't aware of how useful can it be, check Quanta. They use it for quite a lot of nice things :)


I disagree that is a good idea. kdelibs should be for libraries which are the core of KDE, and not for development tool runtimes.

If the kommander runtime was included in kdelibs, why shouldn't the kjsembed, pykde or ruby korundum runtimes also be included?

But a better location for Kommander would be in kdesdk rather than kdewebdev. If kdesdk is not installed as much as kdelibs, then that is the real issue. I think we should try and make kde modules such as kdesdk or kdebindings ubiquitous, rather than attempt to move everything into kdelibs to get the same effect.

By Richard Dale at Wed, 11/10/2004 - 04:26

with rich here. I think we need to push more automation tools as an addon layer for KDE. This way we don't get pet languages in KDE. I don't want to learn Perl, but I know some Python guys who would scream if that became the default KDE scripting language.

By Ian Reinhart Geiser at Wed, 11/10/2004 - 05:22

While I have a lot of respect for Richard and Ian I have to not only disagree with them here but point out they both have pet projects that color their perspectives. First of all Richard, let's consider your point about inclusion. There is nothing like this included with KDE? Kdialog is already in kdelibs and it offers limited use to command line scripting. I think that's great, but do we even put konsole on the kicker by default any more? What about something like kdialog, but with more capability? I do agree with you on one thing Richard, including all those run times would cost a lot of space indeed just to be able to use all those languages with a GUI. Ironically Kommander can already use all those languages and more, though I will grant it may not be as extensive a development tool in many ways it is focused more to end users or application developers than scripters looking to develop applications. A major part of Kommander's mission is to extend existing applicatins and enable visual scripting through DCOP. Would you argue against this? Where is a better solution?

Kommander does not use scripting languages to create or manipulate the GUI. It uses Qt's native *.ui file with custom widgets. The current source for the executor and widgets is roughly 400 MB excluding admin. Ian your presentation at aKademy on KJSEmbed included assumptions about what would not work, which we were already doing with Kommander, and ironically concluded with an anecdotal story of doing several thousand DCOP operations per second with KJSEmbed. The news here is that is what Kommander uses... nicely wrapped DCOP calls is how Kommander works. What is really interesting is that users on the Kommander mailing list are encouraged to post programs where they are having trouble so we can edit and help them. This is because all but the most extensive Kommander dialogs fit under the 40K mailing list limit.

Ian says we should not have pet languages in KDE. I couldn't agree more. Interestingly he's working on KJSEmbed which is Javascript and several applications are adopting it, while others lean toward Python. Personally I like Javascript and I find Ian's approach to integrating it with C++ interesting... but not really all that mainstream for the average user. We are working to make Kommander more easily integrate with any scripting language. If Ian is sincere here in what he says he should be advocating Kommander for application scripting. That way I could build dialogs with it and use PHP for the scripting language. Application scripting should not force a language on me, nor should a GUI tool. Traditionally this has been part of commercial lock in and it should not be copied blindly in open source if there is a way around it. As much as I like Ian and I like Javascript he is doing exactly what he says should not happen, working to cause people to have to use Javascript, and I am doing exactly what he says should happen, working to make sure people can use the language of their choice.

Richard and Ian have projects based on specific scripting languages. What if you're developing end user applications? How nice would it be to be able to offer an instant update to users? Especially since Kommander apps have i18n capabilities, interface with the current version with DCOP, are user extensible for interactive development, run nearly as fast as a native C++ programs and doen't need to be compiled. Add the fact that it has the potential to end the scripting language wars and you would think developers would be treating it like manna from heaven. ;-)

The difference with Kommander is we are actively seeking to address all issues to make the most inclusive and efficient tool to address the needs of users, developers and ALL scripters while hopefully creating a new class of "lite" developers to proliferate small applications on KDE. I really hope developers can get past their pet projects, look at the pros and cons and maybe even give us some help. I continue to be surprised that the guys I think should "get it" still don't. It would be nice to get a little credit from my peers on this, but I'd rather just see the project succeed. ;-)

By sequitur at Wed, 11/10/2004 - 08:40

While I have a lot of respect for Richard and Ian I have to not only disagree with them here but point out they both have pet projects that color their perspectives.

The QtRuby/Korundum bindings are not a 'pet project'. They are a 100% full-on attempt to re-define the state of the art in RAD environments. It is most certainly every bit as serious as the Kommander development effort..

-- Richard

By Richard Dale at Wed, 11/10/2004 - 19:10

QtRuby/Korundum bindings...

Hmmm... I'd like to learn about and play with these too.

Unfortunately kdebindings in HEAD do not compile for me (since I tried it first, a few weeks back). I am using unsermake (and don't want to go deep into "How_do_I_re-define_my_build_process_for_some_modules_to_not_use_unsermake?". Could you make kdebindings compile with unsermake, please? (Mail me for details you need to know, in case it *does* build for you...)


By Kurt Pf. at Wed, 11/10/2004 - 21:37

Why *libs*? kdebase seems a more natural place to me for kmdr-executor....

(It is not a lib. It is not a pure "developers" tool either. It is something that will becume very essential to users, so that they can the dozen and hundreds of little helper utilities that they will find in the web, built with kmdr-editor).


By Kurt Pf. at Wed, 11/10/2004 - 13:14

in practical terms that would mean that KDE WebDev would have a runtime dependency on kdebase, and I don't know if that is wanted (AFAIK, some Quanta users don't use KDE).


By Henrique Pinto at Wed, 11/10/2004 - 15:36

That's correct. Introducing a dependency on kdebase or some other module would hurt lots of our users. Altough Kommander is just a runtime dependency, the functionality would suffer a lot without it.


By amantia at Wed, 11/10/2004 - 16:49

Shouldn't this kind of runtime dependency be solved at the packaging level instead of source module organisation level?

I mean most IO slaves are in kdebase and I guess many Quanta users like the application's ability to manage projects over secure fish or sftp channels instead of unencrypted ftp or manual scp'ing.

Quite some other KDE commandline/base tools are in kdebase as well: kfmclient, kreadconfig, kdialog

By krake at Fri, 11/12/2004 - 11:00