[scribus-dev] Scribus 1.4

[Henning Schröder]

On Sun, May 18, 2008 at 8:42 PM, Craig Ringer
<craig at postnewspapers.com.au> wrote:
> - It offers no sandboxing or limited functionality mode. You cannot
> trust a script you get off the 'net not to exec rm -rf / or go fishing
> for passwords.
Actually I do _not_ want limited functionality. I like the power of
Python because I can use a lot of libraries and I can talk to
databases.
Of course a user should only use scripts he can trust.

> - It's clumsy when trying to isolate scripts from each other. We're
> using a dreadful hack to do it that only works through sheer luck.
> Subinterpreters are designed to be one-per-thread. We can't just spawn
> threads for them, though, since Qt isn't safe for use from other threads
> even when an application-wide lock is used.
Of course multiple interpreters are complicated and threads are a
great cause of problems.
That is the reason scripterng will only spawn exactly one interpreter.
Running scripts in a clean
namespace is still possible if you let Python handle it (e.g. with
"exec myscript in {}").

> The standard tools for wrapping functionality are crude and require
> lots of manual work. Alternate tools, like Boost::Python, require faith
> in large amounts of template metaprogramming black magic that's
> incomprehensible by normal mortals and is likely to break spectacularly
> with Python 3.0 . They're also arguably not much easier to use to
> produce solid, correct code.
Python 3.0 is still far away and I think worrying about it is too early.
I agree that these tools are hard. Because of that I will not use them either.

> - The GUI toolkit module, PyQt, isn't designed for or tested with
> application embedded interpreters. It happens to work, but only with
> some interesting restrictions.
There a lots of huge C++ applications using PyQt and it works for them
(e.g. look at Quantum GIS).
So why shouldn't it work for us? (As mentioned above I circumvent the
sub-interpreters-problem..)

Besides I worked with the author of  PyQt to make sure that some
missing features were added
which are very usefull for PyQt inside a C++ application.
A few days ago there was a new release
(http://www.riverbankcomputing.com/news/pyqt-44) where about 50%
of its new features are related to interaction with C++ objects.

> Compare this to QtScript, which:
>
> - Permits trivial export of app functionality
Now possible with PyQt, too. I will soon add some examples to my repository.

> - Provides useful Qt classes for user scripting
Hmm I don't understand what you mean by useful classes.

> - Has a built in UI engine
Actually you have to make every widget available separately to
QtScript with newQMetaObject and you have to write a QtScript
constructor with newFunction. But you cannot overwrite virtual methods
in QtScript. And you cannot call methods like QListWidget::insertItem
because they are not slots or invokeable.

> - Comes "free" with Qt rather than being an additional dependency
Python is already a dependency on MacOS X and nearly all Linux systems
and PyQt is installed on most KDE-centric distributions. And I guess
the Windows people do not really care about disk space ;-)

> I'm just not sure that new python bindings to replace old Python
> bindings is the right answer, even if the new ones do use a cleaned up
> and simplified C++ interface and use a wrapper generator.
They don't use a wrapper generator ;)


-- 
Henning