Extension script discussion

From Scribus Wiki
Jump to navigation Jump to search
This article is part of the Scripts series.

Discussion of extension script matters

Any discussion of extension script plans, issues, etc should probably happen here. The Known Scripter Issues and Cool experimental PyQt stuff pages may also be of interest.

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.
  • Hooks

Hooks

For listen-only hooks, Scribus doesn't need to do much more than emit a signal that scripts and plugins can connect(...) to. However, the event loop won't be running when the hook gets called, and there may also be certain things it's unsafe to do because scribus just isn't expecting them. For that reason, in some cases it might be better to use posted events rather than signals.

Where signal-based hooks would be really useful would be where the script can affect how things run. For example, the script might want to run some additional checks when PDF export is requested, and might display a dialog letting the user cancel the operation if the script finds problems (think: "Text box `story' contains data that's out of date according to the CMS"). For this, the script would connect(...) to a signal, and would be able to call a method like abortCurrentOperation() in the core code to indicate the user request to cancel. We can't just have the signal return a flag since, being one-to-many calls, they can't have return values.