[Scribus] Differences between startup script and regular script

[Craig Ringer]

Yegor Jbanov wrote:
> Hi,
> 
> What is the difference between running a Scripter script during
> startup and running the same script using the Script menu?

A startup script is run once when the scripter loads, and runs as an
extension script so it can use PyQt etc.

Startup scripts were put in place to make it possible to load Python
based extensions to Scribus automatically.

Note that the startup script runs when the Python interpreter loads.
This is well before the main window exists. A Qt signal, appStarted(),
is emitted when startup is complete. You can only get this signal with
PyQt; there is no hook mechanism provided in the scripter to invoke any
arbitrary Python function on the signal. It wouldn't be too hard to
write a C++ scripter function to set such a handler function and invoke
it on appStarted().

A PyQt example showing how to handle the appStarted() hook can be found
in plugins/scriptplugin/samples/startup_hook.py .

As a side note, appStarted() and other "hookable" signals should
probably be processed as deferred signals in the event loop in 1.3.5 .
This would help solve problems with reentrancy and make more
functionality safe to invoke from hook-triggered Python functions.

> I wrote a script which embeds a simple HTTP server into Scribus
> (BaseHTTPServer provided with standard Python). When I run it from the
> menu it works. I can access the server from the browser and the server
> can access Scribus API and generate output from my documents.
> 
> When I run it as a startup script Scribus crashes with a message
> "Scribus crashes due to Signal #11" upon the first HTTP request from
> the browser.

Any chance you're trying to do real work before Scribus has fully
started up?

> Here's the console output:
> 
> Scribus Crash
> -------------
> Scribus crashes due to Signal #11
> Calling Emergency Save
> Saving: /tmp/scribus-server/serverpI2QPI/processors/invProc/invoice.sla.emergency
> Segmentation fault (core dumped)
> 
> (remind me again where does the core gets dumped so I could analyze it?)

Rather than analysing a core, you are usually better off running Scribus
under gdb.

gdb --args /path/to/scribus
(gdb) run


when Scribus crashes, it'll appear to "freeze" instead of displaying a
crash handler dialog. The gdb prompt will show up in the terminal you're
running gdb from, and you can explore the state of the program from there.

You'll want a version of Scribus built with debug symbols (
-DCMAKE_BUILD_TYPE=debug ) to get much information out of a debugging
session, though.

> I am not sure where exactly it crashes in my Python code. I will
> investigate further.

A backtrace would be really helpful. Run Scribus under `gdb' as
described above and when it crashes, run the `bt' command:

(gdb) bt

then post the crash message from gdb (the bit near "Program received
signal SIGSEGV, Segmentation Fault") and the output of the `bt' command.

--
Craig Ringer