From kde-core-devel  Sat Feb 24 13:55:09 2007
From: Jakob Petsovits <jpetso () gmx ! at>
Date: Sat, 24 Feb 2007 13:55:09 +0000
To: kde-core-devel
Subject: Re: organizing kdebase
Message-Id: <200702241455.09978.jpetso () gmx ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117232534428680

On Friday, 23. February 2007, David Faure wrote:
> On Thursday 22 February 2007, Aaron J. Seigo wrote:
> > On February 22, 2007, David Faure wrote:
> > > On Thursday 22 February 2007, Aaron J. Seigo wrote:
> > oh, it's not about C++. if Ruby or Python apps used these tools, that'd
> > be enough. the language used is not relevant, the kind of application is.
> >
> > let's say i did an `$PACKAGE_MANAGER install kfoo`, that should pull in
> > kdelibs and kdebase/runtime. the latter should have only what is really
> > the runtime for such applications. kfoo, regardless of what language it
> > is written in, should not be using kwriteconfig.
>
> ... unless it's written in bash.
>
> That's the point. If (or given that) we provide enough tools, you can make
> useful addons in shell scripts using kdialog, kread/writeconfig, etc.
> Those scripts have runtime requirements: kdebase/runtime.

Actually, this made me wonder about the difference between tools made for 
shell scripting and language bindings. Like in:

- You need kdebindings to execute Ruby/Python/whatever apps
- You need the kommander runtime environment to execute kommander apps
- You need tools/ to execute KDE-enabled shell scripts

From that point of view, tools/ doesn't seem to be anything different than the 
language bindings for shell scripts. So if you include tools/ in runtime/, 
where do you stop? Shouldn't the kommander runtime also be in there?
Don't we need the Ruby and Python bindings to execute such apps?
After all, those are scripts as well, and can similarly be downloaded, written 
and run on-the-fly without needing to compile anything, or make a binary 
package, or set up your standard C++ development environment.

Why should we want shell-enabling tools in runtime/, but leave out Ruby in the 
same breath? I think Aaron's reasoning was not so far off in this respect.

Apart from that, I'd find it a good thing if those dependencies for
non-C++ languages get a more prominent place.
(No need to move tools/ to kdebindings =)

Sorry for resurrecting the already extensive thread, but I needed to get this 
out. Wishes,
  Jakob