Improve scripting and its experience in Scribus: Difference between revisions
(Implementation details) |
(Security issues) |
||
| Line 19: | Line 19: | ||
As you see in the current state scripter is already powerful but it lacks | 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. | * 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. | * 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. | * 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. | * 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 below] | ||
== Security == | |||
Python has absolutely no way to ensure that code can be "checked" a-la perl restricted mode or Java's bytecode security model. The restricted python mode was proven to be ineffective and has been removed. Every suggestion anybody has ever come up with as to how to restrict Python programs with the CPython interpreter has been proven to be breakable (see innumerable discussions on the newsgroup - I won't repeat the whole large topic here). Under these circumstances we would be instilling a false sense of security by offering any sort of restricted mode to users. | |||
If you want a secure language for automation, embed Lua, (maybe) Qt Script for Applications (an ECMAScript/JavaScript implementation), or even restricted mode Java. Python is not suitable. | |||
What we need to do is ensure that documents either (a) can NEVER embed scripts, or (b) can embed scripts but ONLY run them if the user specifically turns that on in the prefs AND accepts a prompt when opening the document. We might use a signing scheme to permit the prompt to be disabled for trusted script publishers as nominated by the user. This prevents the document virus problem we see in MS Office. | |||
Personally I don't think we should permit script embedding in documents at all. Make the user install the script and understand that by doing so they give it the same rights as any other program they install on the system. If we want to support script embedding, we're better off choosing a more restricted language for that and leaving Python for extending the app and for advanced scripting with GUIs etc. | |||
== How to make scripting situation better == | == How to make scripting situation better == | ||
Revision as of 05:05, 17 March 2007
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++
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 below]
Security
Python has absolutely no way to ensure that code can be "checked" a-la perl restricted mode or Java's bytecode security model. The restricted python mode was proven to be ineffective and has been removed. Every suggestion anybody has ever come up with as to how to restrict Python programs with the CPython interpreter has been proven to be breakable (see innumerable discussions on the newsgroup - I won't repeat the whole large topic here). Under these circumstances we would be instilling a false sense of security by offering any sort of restricted mode to users.
If you want a secure language for automation, embed Lua, (maybe) Qt Script for Applications (an ECMAScript/JavaScript implementation), or even restricted mode Java. Python is not suitable.
What we need to do is ensure that documents either (a) can NEVER embed scripts, or (b) can embed scripts but ONLY run them if the user specifically turns that on in the prefs AND accepts a prompt when opening the document. We might use a signing scheme to permit the prompt to be disabled for trusted script publishers as nominated by the user. This prevents the document virus problem we see in MS Office.
Personally I don't think we should permit script embedding in documents at all. Make the user install the script and understand that by doing so they give it the same rights as any other program they install on the system. If we want to support script embedding, we're better off choosing a more restricted language for that and leaving Python for extending the app and for advanced scripting with GUIs etc.
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
- 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.
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
- (more to come soon)
See the links below to see that I already have experience in this area.
