Known Scripter Issues

From Scribus Wiki
Revision as of 12:38, 20 October 2006 by Cmartin (talk | contribs) (Known Issues)
Jump to: navigation, search
This article is part of the Scripts series.

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

Common Issues

Error Importing Python Modules

I was getting an error in my python scripts when I was trying to import modules using commands such as:

import Image

I was running Scribus on Windows XP. I had Python 2.4 already installed on my machine before I installed Scribus.

One of the helpful people on the Scribus IRC suggested the I delete the following files/folders from my Scribus installation:

File: python24.dll Folders: lib, dlls, tcl

After that, Scribus ran scripts using the original Python installation. I'm not sure if all these folders needed to go.


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.

A question about threading that covers some of the issues
Some discussion specific to Qt issues

Some documentation on using PyQt with the extension script system has now been written and will appear in 1.2.2cvs shortly.

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.

Known PyQt issues and limitations

Please record any known issues with using PyQt in Scribus here.

  • Threading may not work (ringerc)
  • issues accessing the main window; qApp.mainWidget() returns a QWidget (will be solved in upcoming PyQt release)
  • PyQt crashes scribus if run from a normal script

See also

It's probably also worth checking out Extension script discussion, which will cover some more matters about the developing extension script support.