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
