Known Scripter Issues: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
(Added discussion / request for comments on open issues)
No edit summary
Line 30: Line 30:


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.
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.
==== Open Issues ====
These areas need work, consideration, and discussion. The more (considered and useful) feedback and ideas, the better.
* Extension scripts
** How to make it easy for the user to differentiate extension and normal scripts
** How best to load extension scripts (I'm now tending toward importing as modules then running a function in the module)
** How best to explain what an extension script is vs a normal script
** Should I impose an import hook to prevent loading of PyQt in normal scripts (since it'll crash Scribus)?
** Worth looking into sip bindings for the Scribus-specific GUI classes?
** Provide a standardised way to delay initialisation of scripts until app loading finishes
* Scripter core
** Property/object based interface is working in 1.3. Do we care about doing automatic unit translation, or is it better to just let the user say '1*in' in arguments? I favour the latter.
** A basic object-based interface is now possible. How should it look?
* Dependencies
** What issues do folks have with dependencies such as sip or libboost for scripter? I don't want to make any such deps required for basic function, but it might be possible to do some cool optional functionality with them.


==== Known PyQt issues and limitations ====
==== Known PyQt issues and limitations ====
Line 54: Line 37:
* Threading may not work (ringerc)
* Threading may not work (ringerc)
* issues accessing the main window; qApp.mainWidget() returns a QWidget (Henning Schröder, via ringerc)
* issues accessing the main window; qApp.mainWidget() returns a QWidget (Henning Schröder, via ringerc)
* 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.

Revision as of 06:20, 17 February 2005

This article is part of the Scripts series.

Known Issues

FAQ

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

GUIs

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 (Henning Schröder, via ringerc)
  • 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.

Retrieved from "https://wiki.scribus.net/wiki/index.php?title=Known_Scripter_Issues&oldid=4206"