[Scribus] Has any thought been given to using Kross in Scribus

[Craig Ringer]

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
>> dependency
>> for Scribus - kdelibs etc.
>> Well, I don't have anything against KDE (I use it) but I think our planned
>> Boost
>> interface should be better to maintain. Of course I can change my oppinion
>> depending new informations.
>>
>> petr
> 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:

http://kross.dipe.org/apidoc/dir_9a406c12b30640355ae36232cdc8ea5e.html

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.

--
Craig Ringer