Known Scripter Issues
First of all, please see the Scripter FAQ for a discussion of some common questions and problems.
If you have any proposed changes for the FAQ, feel free to put them here.
One thing that needs a bit more coverage than it currently gets in the FAQ is the issue of using GUIs. For now, I'll just link to a few of my mailing list posts on the topic. These posts are pretty technical answers, so I need to write up something a bit more readable later.
In brief summary, the main issues are:
- The use of sub-interpreters and the resulting problems with loading of some C extension modules, including PyGtk and PyQt
- Non-modal windows (that let you continue to interact with the app) can't be created in sub-interpreters because the script's data is destroyed when the script ends, and Scribus's execution cannot continue until the script ends.
- Event loop integration if you want to use PyGtk or Tkinter without "locking up" the Scribus GUI
With the macro manager patches integrated into 1.2.2cvs, you can now use PyQt and create non-modal windows such as extra palettes by writing a script that is run from 'Load extension script'. The script does the setup, creates the window, then exits - but when it exits its data is not destroyed, and its windows continue to execute as part of the Qt event loop, calling Python functions when events are triggered.
I've also been able to successfully use Tkinter to create windows in scribus without "locking up" the main interpreter. This involved hijacking the Scribus event loop and putting Scribus under the control of its embedded Python interpreter. Not pretty. Expect a cleaner solution involving the registration of timers to call other toolkits' event loops to come later.
It should be obvious by now that building Python GUIs for use in scribus is a non-trivial task. For now, stick to using Tkinter for most GUI work, or use PyQt with "load extension script" if you want to build new palettes and other things that hang around while you continue to work in Scribus.