Abiword report generator [was Re: Dynamic data queries]

[msevior at physics.unimelb.edu.au]

> On Sat, Mar 06, 2004 at 12:15:06PM -0600, Linas Vepstas was heard to
> remark:
>> On Sat, Mar 06, 2004 at 02:44:10AM +1100, msevior at physics.unimelb.edu.au
>> was heard to remark:
>> > >
>> > > (One of the great Lotus Notes emails was the infamous job
>> satisfaction
>> > > survey.  The question "Are you satisfied with your job?"  Two
>> buttons
>> > > you could push to answer: the Yes button, and the No button, which
>> > > would skitter and jump out of the way every time you tried to
>> position
>> > > your mouse anywhere near it.)
>> >
>> > I can imagine how we might implement text or image based live feedback
>> in an
>
> I thought about this some more and realized I was expressing myself
> unclearly.  Let me try again.
>
> Abiword docs have two representations: first, as a static (xml) file
> that live on disk, and secondly, as a set of C structs and objects and
> code in system memory when the document is being displayed.  The
> second form is what I call the "live" document.   It takes a lot of cpu
> cycles to convert the file-formate representation into the live
> representtion.
>

Well mostly C++ classes but carry on, I get it :-)

> To make an abi document 'animated', one could, of course, modify
> the file contents and tell abi to redisplay.  The downside is
> that this eats a lot of cpu time, esp for what might have been a
> 'trivial' change.
>

No we'd never, ever do this.

> That's why working with the live document is 'better'.  There's
> two ways to do this, let me call them the 'call-back way' and the
> 'attribute way'.   In the callback way, the document is read into
> memory, and then drawn to the screen.  During drawing, abi calls
> callbacks for the various text blocks, etc. and my app can make
> last-minute changes to the document in those callbacks.  I don't
> like the callback way.
>

OK this is something like what I was talking about implementing with
Rodrigo. We update fields from a data source in real time.

> The 'attribute way' was the method I was trying to describe before:
> after the document is read into sytem memory, but before its displayed,
> the app searches for and locates certain named text blocks, modifies
> them, and when done, tells abi to go and display the doc. Animation
> is by making a small change and asking abi to redisplay.   I like the
> 'attribute' approach a whole lot more for a large variety of reasons.
>

OK we could do this securely if Abi was linked into your app's address
space or if it was specfically invoked with the PID of the calling process
or if activated as a bonobo component.

Furthermore, there is no reason your changes to the document need to occur
before the document is displayed on the screen. We could implement a
listener in the AbiWord gtk main-loop and have the document respond to
"events" and data generated from your app.

The AbiWord document model, which we call the piecetable, has arbitary
collections of named properties. We just invent a property called, say,
"external-source". The value of the property of the "external-source" is
some unique identifier which your app would use to specfiy what gets
changed.

The listener in the AbiWord  main-loop responds to events from your app.
You specify what unique-id you want changed and tell abi what the change
is. It could be different text, it could be changed properties (boldness,
font, colour etc). It might even be different stuctures. (Turn a 4 column
table into a 10 column table).

It could be anything we currently do via the GUI. The only difference is
that it's remote app that does it.

It would work because we could map regions of matching "external-source"
properties to locations within the document and apply our standard
document manipulation techniques to that region.

We could even handle discontinuous regions with identical external source
ID's.


The listener performas the changes on the piecetable and the document will
update it's onscreen representation.

> I hope this wasn't a too-simplistic restatement; after the last email,
> I was concerned that there was some confusion.
>

Not at all. It helped enourmously. I can now now see exactly how to do
what you want. I can even start sketching out an interface.

Cheers

Martin

> --linas
>
> --
> pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
> PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933
>