[Scribus] Yet ANOTHER scripting bug

[Craig Ringer]

Chris Bergstresser wrote:
> Hi --
> 
>    I'm really getting frustrated with the quality of Scribus.  The
> latest bug (I assume bug) is the following:

I'm getting really frustrated by people who have problems not mentioning
their Scribus version :-P

More seriously:

1.3.5 is in development, consequently buggy, and has a largely
unmaintained scripter. Things will be broken. It's not unlikely that the
scripter will get thrown out and replaced with a new, more maintainable
implementation.

1.3.3.x should generally be OK. There are some known issues (quite a
few), but it should tell you when you've made a call it can't act on.
More specifically, if it's the scripter its self refusing to accept the
operation it'll throw an exception, and it'll also try to detect errors
from the Scribus innards and throw then. Unfortunately, Scribus's
internals don't use exceptions to report errors, nor do they have any
error logging/return code system. They tend to silently ignore invalid
arguments, calls in inappropriate contexts, etc. The scripter cannot
usually detect these issues, and certainly can not do so without
duplicating a lot of (oft-changing) logic from the program internals.
The Scribus core is being cleaned up, including its error handling, but
it's a very slow process especially given the limited number of folks
who can work on it.

1.2.x is obsolete. Avoid. Also, in older point releases its scripter
behaves more like the Scribus innards and ignores errors silently or
returns an error code rather than throwing.


Note that in every version of Scribus the scripter's functions are each
hand-written to wrap Scribus internal functionality, check parameters,
handle errors, etc. It's laborious, error prone, and hard to maintain,
and there are definitely problems.

I got into Scribus development by fixing Scripter bugs that annoyed me,
learning basic C++ in the process (and doing surprisingly little harm,
all things considered). In fact, that's why the scripter throws
exceptions on errors like the rest of Python instead of failing silently
- it bugged me so much. If that approach doesn't interest you, then your
best option is to identify specific problems in as much detail as
possible and report them. I don't think scripter bugs see much attention
or get much priority at present (since the system is horrible to work on
and hopefully going to be replaced), but the commit logs do show some
fixes.

It's also important to ensure that your code isn't throwing away
exceptions. They contain important information about what went wrong and
what the system was expecting. Avoid code like:

try:
   # some Scribus scripter calls
except:
   pass

since by doing that you're silencing the diagostic messages that might
help you resolve an issue.

--
Craig Ringer