[Scribus] Maintaining text with scribus

[Craig Ringer]

avox wrote:
> 
> Asif Lodhi wrote:
>> Hi Greg,
>>
>> On 6/13/06, Gregory Pittman <gpittman at iglou.com> wrote:
>>> What I meant was that, since Scribus does not (yet) have an internal
>>> spell-checker ...................................
>> I think it would be great if the developers could provide us users
>> some kind of an object-based programming model
>> (scriptable/programmable) for Scribus like all MS-Word, Excel, etc. do
>>
> 
> Would be great if the developers had a nice C++ object-oriented programming
> model for Scribus ;-) -- but we are getting there.

Yep. That's been the limitation on such an API for Python - the lack of 
any clean API in C++ to build on and wrap. As Andreas notes, things are 
getting better. Hopefully it'll be possible to produce a common API for 
plugins (C++) and scripts (Python) that helps isolate the scripter and 
plugins somewhat from internal changes once the 1.3.x series settles down.

I don't think there's any chance of an improved API going into 1.3.3.x 
or 1.2.x . You'll note a scripter2 directory in 1.3.3.2 - that's a test 
version of a possible approach to the C++ interface that uses 
Boost::Python . Doubt if you can build it now, though, at least in 1.3.x 
. I'm hoping that Boost::Python will provide a good way to neatly wrap a 
C++ plugin API for scripting use, including full control over the new 
text engine, etc.

For now, though, any scripting improvements are waiting on core code 
changes and cleanups. Trying to start now would be - as I discovered - a 
constant uphill battle against changing internal interfaces.

>> by providing VBA-based object-models "with programmable events" so
>> that you can write event-handlers, for example, when a document is
>> saved in Microsoft Word, and so on.

VBA-based? Or VBA-style?

A VBA plugin might be an exciting project for a Windows scribus user, 
but I doubt you'll find anyone on the team particularly excited about 
tackling it. Since the win32 versions are currently a real pain to build 
it's not overly practical yet either, but hopefully that'll change in time.

>> An object-model based on Python would be just great - event-points
>> (story_editor-story-is being-copied-to-the-text-frame,
>> .sla-file-is-being-saved, font-is-going-to-change, etc.) will have to
>> be carefully identified and exposed though.
>>
> 
> I'm not a fan of scripting interfaces which allow interception of internal
> Scribus events...

To be honest, it's something I'd be interested to have available as 
well, Andreas. Only at points where they can be done cleanly and the app 
is in a sensible state (which pretty much means before and after the 
event in question), but I'm not sure it's a bad thing once the code is 
tidier. Right now it wouldn't work very well at all, though.

I'm not sure I'd be up for internal events that can be blocked or 
altered, but notification of them would be helpful. That should be as 
simple as emitting a signal ( emit appEvent_DocumentSaved(doc) ) ; let 
the scripting interfaces deal with how to translate that into something 
useful for them. I already have a good idea of how to handle it for Python.

> OO model for docs/item/styles would be fine, also methods for configuring
> menus, toolbars and creating of new actions. Also all kinds of import/export
> functions of course.

Yep. Some of that is already possible if you're willing to get dirty 
with the innards of the application using PyQt . It'd be nice to do it 
more cleanly through public scripting/plugin API.

>> Also, what do you think about the idea of having the story-editor
>> facility as a configurable option instead?  I mean the users being
>> able to configure the editor of their choice as "the Scribus'
>> Story-Editor" so that they get to edit their text in their favorite
>> editors with all the facilities they want - that is, their favorite
>> editor pops-up when they select the Scribus' story editor option.
>>
> 
> Possible, but how would Scribus export the style information? And
> import it back?

This might sound easy, but there are types of styling information that 
Scribus understands but many other apps don't. As the 1.3.x series 
improves that gap in styling facilities will only grow. It's rather hard 
to round-trip styled text through an app that doesn't understand many of 
the styles you need.

I'd love to hear suggestions on this one, as it'd also apply well to the 
external (linked) text ideas that've been floating around for a while.

--
Craig Ringer