[Scribus] Maintaining text with scribus
Wed Jun 14 04:59:22 CEST 2006
> 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 184.108.40.206 - 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.
More information about the scribus