organizing kdebase
Jakob Petsovits
jpetso at gmx.at
Sat Feb 24 13:55:09 GMT 2007
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
More information about the kde-core-devel
mailing list