Talk:Improve scripting and its experience in Scribus

Discussion

... on the final proposal

(Added by CR after the proposal was uploaded:)

The proposal that was submitted seems sound, with sensible goals that are achievable starting with the current code base. It seems vastly better than what the initial outline on the wiki described, and should be amenable to being adapted to a new and more complete scripting interface if anyone ever finds the time to write one.

On the earlier proposal ideas/outline

[CR: The very first step we need is a sane internal API that we can expose for scripts to use - including SIP wrappers for parts of the GUI that we want to open up for manipulation, etc. Discovery through Qt's parent/child mechanism is limited and clumsy. With a decent C++ API and a SIP wrapper we can start making more sane, powerful scripts - and can probably integrate script management into the existing plugin manager.]

Answer to CR: Of course it would be great to have direct access to all objects and their methods. And this would be a great final goal. Currently with the introspection features of Qt (children, queryList, allWidgets, ..) you can only get the base classes, so you get QMainWindow and not ScribusMainWindow. Wrapping everything with SIP is a large task and I think it should be done bit by bit when something is needed. I am currently looking what needs to be done to wrap Scribus classes with sip. As an interim solution it would already helpful for finding an widget if most widgets in Scribus would have an internal name which can be set with QObject.setName or with the constructor. Then already a lot is possible. Hooking into the GUI, responding to signals etc can be done.

CR: reply: Full access to every internal Scribus method really isn't ever going to be realistic, nor would it be useful. There's a lot of internal functionality in Scribus that neither scripts nor plug-ins should ever see or be able to see. Much of it also changes quite quickly, so exposing it would cause major compatibility problems. For example, a plugin or script should not be aware of, or have to care about, the details of how text is represented in Scribus's internal data structures ... it should just get access to a somewhat higher level API for text manipulation. What I suggest is that an important initial step before any sort of serious effort to expose more of Scribus to scripts is to provide a sane C++ API that hides much of these internal details behind more stable and somewhat simplified interfaces. These interfaces could then be wrapped using SIP for use by scripts and plug-ins.

That, in my opinion, would be a really GREAT GSoC project. I also think you have some great ideas with regards to making scripts easier to find, providing sensible and consistent ways to install them, etc. Don't let me discourage you ... I'm not trying to, I'm just trying to point out potential issues with the approach rather than goals.

That's not to say that permitting full introspection via PyQt (tagging everything with object names) is inherently a bad idea, but it will lead to scripts that'll only work for one particular version of Scribus. They'll sometimes break even on patch releases. It's useful as an interim step, I agree, but it's not something I'd ever seriously rely on. Wrapping Scribus's internal objects with SIP isn't much better, either, since they're hardly API stable. IMO we _REALLY_ need a more stable C++ API to expose Scribus's functionality to scripts and plug-ins. I spent quite a long time maintaining the scripter alongside Petr, so I am all to familiar with how much breakage there is from version to version and how hard it can be to keep up.

I'm also very strongly in agreement with you in terms of the desirablity of hooks into Scribus for use by scripts and plugins. I've been thinking about that for a while; see extension script page referenced below.

Some articles on the wiki that may be of note: Scripter Security, Known_Scripter_Issues, Experimental_PyQt_projects and Extension_script_discussion .

CR: Do you have a good idea of what form the new API will take? Malex 00:51, 31 March 2007 (CEST)

Malex: Honestly, no. API design like this is *HARD*, especially when going for something that makes sense as Scribus advances. The existing scripter, and the recognised limitations in it, provide some ideas about some of the things people need to be able to do through such an API, though, as does what plugins are currently doing. What we need to do is look at how these tasks, and ones that people want to be able to do but can't do, are being done right now, and how we can help make them easier and saner. Some internal changes will be needed too, such as finishing the page item separation to the point where factory-created page items that can be supplied by plug-ins are viable. Unfortunately, what's needed here is to sit down and spend a LOT of time examining use cases, thinking very hard about usability of the interfaces and the simplicity-vs-flexibility trade off, etc. Lots and lots of time. That's why nobody, myself included, has jumped to do it yet, though both Petr and I see it as a necessary step before we can really make much progress improving the scripter or making plugins easier to write. --Ringerc 22:02, 2 April 2007 (CEST)

Question : scripter2

Could somebody say how this here described project vision relates to the "new" scripter2 that was coded by Jain during GSOCs ? How satisfying is scripter2 relating to these goals ?