Improve scripting and its experience in Scribus

From Scribus Wiki
Jump to: navigation, search
Archive icon.png
This article is ARCHIVED. It is a part of the Scribus Community's history and is kept here for reference and as a representation of the contributed efforts. It is protected from editing, but its source can be copied.

Introduction

The potential of the scripting interface seems highly underestimated. You can

  • add features without knowing C++ and without recompiling
  • make something which directly fits your own needs
  • automate repetitive tasks to improve usability and to save time
  • test ideas - Python is great for prototyping and sometimes it makes more sense to improve the prototype instead of rewriting everything in C++
  • use functionality that does not exist or would introduce dirty dependencies like for example using PyUNO to access OpenOffice.org (it's even possible to run OO.org in the same thread the qapp runs in) or reportlab.org which allows to create easy custom PDF's using some XML-templates or whatever...

I actually have written prototypes (among others) of

  • new-document-wizards
  • spell checkers
  • importers for exotic file formats
  • connectors to databases and content management systems
  • GUI hacks (full screen mode, tear-off menus etc.)

Current problems

As you see in the current state scripter is already powerful but it lacks

  • full integration into the GUI and the core: Scripts cannot easily add menu entries or toolbar icons, save settings into the Scribus configuration file, etc. [CR: This will probably need a decently designed public C++ API for Scribus, plus a SIP wrapper for it]
  • completeness: While writing scripts you sometimes find things which are still missing. For example there is a function to zoom the document view. But there lacks a function to get the current zoom factor. [CR: Again, need a real public API in C++ to make any kind of completeness effort viable and maintainable]
  • ease of use: The script console is really minimalistic and needs improvement. Also there is no standard way to distribute and install scripts.
  • security: Scripter should warn you if a script wants to import a module which can access the file system. The user should be asked if he trusts a script. [CR: unfortunately the first part of this is not viable, though the second is - see Scripter Security ]

How to make scripting situation better

So what is needed?

For the user

  • a standard way to find and to install extensions and scripts from the web, preferably from a trusted repository [CR: Great idea, especially if combined with signing of scripts for integrity etc]
  • scripts look and behave as native parts of Scribus

For the developer

  • specifications on how scripts can be integrated with Scribus
  • more example scripts / extensions to see what is possible and how to make use of Scribus' features
  • completed missing functionally


My idea

So I propose writing an extension manager for Scribus together with some example scripts and extensions.

This will probably help to find missing functionally and integration issues. Currently it is very easy to write scripts and this should not become harder by adding this new layer.

Mozilla Firefox shows what is possible with easily installable extensions. People without knowledge of C-programming can realize crazy ideas and useful features. A lot of the popularity of Firefox comes from its add-ons.

[CR: discussion moved to The talk page for this article.]

Implementation details

The GUI part will use the PyQt library which can directly integrate with the Scribus GUI. PyQt is available on all platforms where Qt is available and also supports Qt4 which Scribus will soon use. Nearly all Linux distributions contain PyQt and some like Kubuntu install it by default.

Most parts of the extension manager can be implemented in pure Python and rely on the already available hooks in scripter. Besides some stuff has to be added:

  • functions to get the configuration directory and the program directory
  • some widgets need to have a name so PyQt can find and access them
  • Bindings for the preferences manager [CR]
  • Bindings for the menu manager [CR]
  • (more to come soon)

See the links below to see that I already have experience in this area.

Links




Excerpt from submitted abstract and application to GSoC 2007

Rationale

Scribus shows that serious desktop publishing is possible with free software. Scribus has many powerful features which are commonly mentioned in articles, e.g. the high quality PDF export and the color management. But the potential of the scripting interface is mostly underestimated. The Scripter plug-in is included in the Scribus main distribution together with some example scripts. However it does not get the attention it deserves in my point of view. Because of that I want to show what is possible with the Python scripting interface in Scribus.

Overview

Other open-source projects like Firefox, Blender, Inkscape, OpenOffice or Gimp have shown that bindings to scripting languages result in many new features and contribute largely to the success of the application. People without knowledge of C/C++ but some Python-, JavaScript- or Perl-skills can easily write import-/export-filters, create wizards, write plug-ins or realize something nobody else has thought about before. The distributed scripts can be used without recompiling and even without knowledge of the scripting language.

Scripts can help to automate tasks and can fit the special needs of a user. Also it is possible to test new ideas. Languages like Python are great for prototyping. And sometimes it makes more sense to stay with Python instead of rewriting everything in a compiled language.

As Scribus already provides a good basis with its Scripter plug-in I want to improve it and its usability. To show the power of the scripting interface I want to write some small and some larger example scripts (resp. extension scripts). My idea is that Scribus needs a script-/extension-manager like Firefox has for themes and add-ons. Like Firefox a user can browse the scripts on a website and install them by just clicking a link. So my task will also include building a small web application to provide a repository of scripts.

So the project consists of three tasks which are mutually dependent. 1. The script-manager based on PyQt and its QTextBrowser 2. The example scripts and extensions. Planed are an OpenClipArt browser and a simple spell-checker. 3. The repository. Either a CGI or a script which generates static pages

At each task I will determine which functionally is missing and how these sub-projects can be linked together. This will show what needs to be done in the scripting interface. Currently scripts do not look like native Scribus components because e.g. they cannot be connected to menu-/toolbar-entries or context-menus. There is also no standard way to install scripts to make them automatically available. These things need to be addressed. Some implementation issues will be discussed with the Scribus team, e.g. about security (already partly done), integration or future directions. Currently there are thoughts in the Scribus team about creating new automatic bindings. Because of that I will do two things: 1. I will try to keep my code modular and flexible. It should be relatively easy to port the script-/extension-manager to the new bindings when available. 2. I will evaluate different binding generators (sip, swig, boost, smoke) and make tests to see which will be the best path to go (probably sip with a separate C++ API)


Benefits

1. Firefox showed that people liked the flexibility to install add-ons. My project will bring this feature to Scribus in the hope that people will enjoy Scribus even more and it will attract new users. 2. The script interface and its experience will improve which will hopefully attract new script writers. 3. Scribus gets a repository for scripts anyone can easily access. I would be willing to host it after the GSoC. 4. Some C++ code is not needed anymore and could probably be removed, e.g. the script console. I already wrote a better replacement in PyQt.


Deliverables

  • a script manager
  • example scripts
  • a script repository
  • documentation for the script writers