[scribus-dev] Scribus 1.4

[Craig Ringer]

Henning Schröder wrote:
> 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.

As do I - I think it's important and useful to have. I guess I just 
really wish Python had a restricted mode like Perl's or (better) Java's.

> Of course a user should only use scripts he can trust.

Experience suggests that most people are not capable of evaluating the 
security of programs offered for download on the 'net. Being able to 
offer some kind of assurance that scripts can't access the file system 
without permission, for example, would be very nice.

> 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 {}").

OK, that helps.

I had persistent memory management issues when trying to do that, but 
that was some time ago and I was invoking the script in a separate 
global dictionary with the Python/C API.

Using separate global dicts doesn't provide all that much protection 
against scripts stomping on each other through changing module settings, 
etc, but then neither do subinterpreters.

>> - 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..)

Avoiding the use of subinterpreters is a major step toward making PyQt 
useful.

> 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.

I see that they've improved support for the metaobject system. That 
would indeed make a huge difference. The metaobject system in Qt3 was 
just a bit too limited to be much use for bindings, which is why I was 
muttering about the necessity of using SIP.

If with Qt4 you can avoid the need for static SIP bindings by using the 
Qt metaobject system then Python - and PyQt - starts to look at lot more 
attractive.

>> - 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.

Unfortunate. I was under the impression that it was a bit more flexible 
than that - but that's why I wanted to do some testing with QtScript.

I was under the impression that subclasses with overridden virtual 
methods were possible. If not, that's unfortunate, but not that big a 
deal for using QtScript as an automation language rather than an 
extension language.

--
Craig Ringer