[Scribus] Has any thought been given to using Kross in Scribus
Tue Jul 11 14:26:22 CEST 2006
David Goodenough wrote:
> On Tuesday 11 July 2006 11:39, Petr Vanek wrote:
>>> Kross for those who have not met it is the new scripting framework being
>>> put into Kexi and then the rest of KOffice. It has the merit that is
>>> entirely separates the scripting language from the scripted application
>>> thus (eventually) allowing support for lots of scripting languages to be
>>> added to an app as easily as adding one. Currently support seems to be
>>> for Python and Ruby, with Ecmascript and Java coming soon.
>> I've read about Kros last weeks. It looks promising but it brings new
>> for Scribus - kdelibs etc.
>> Well, I don't have anything against KDE (I use it) but I think our planned
>> interface should be better to maintain. Of course I can change my oppinion
>> depending new informations.
> Maybe the lower levels of the two could be merged, so that the core which
> is the scripting language interface bit of Kross could be separated from
> whatever dependancies it has on KDE and used within Boost.
When Petr mentioned Boost, he was referring to Boost::Python, a Boost
library intended to make it easier and saner to produce Python bindings
for C++ code and to mix Python and C++ code. As that is scripting
language specific, it wouldn't make much sense with a system like Kross.
It's often impractical to untangle things from KDE code. When it is
done, it's often ... messy. There are certainly cases where it's worth
doing, but a scripting framework might not be one of them - *if* it's
tightly bound to the low level KDE tools. It's important to understand
that KDE isn't just a GUI toolkit - it provides new, fundamental tools
for building programs.
Here's the Kross CVS:
At a quick glance it looks pretty nice. More interestingly, it looks
like the authors may have specifically designed it not to depend too
tightly on KDE. They use some KDE components, but it looks like some are
designed to be swapped out (eg KSharedPtr -> boost::shared_ptr or
tr1::shared_ptr) and others may only be required if binding KDE code
(like the KAction stuff).
Given that it seems to avoid depending too tightly on KDE's innards, it
might well be worth investigating.
More information about the scribus