[gnome-db] Re: Abiword report generator [was Re: Dynamic data queries]
- From: linas linas org (Linas Vepstas)
- To: msevior physics unimelb edu au
- Cc: Linas Vepstas <linas linas org>, Dru <andru treshna com>, gnome-db-list gnome org, Charles Goodwin <charlie xwt org>, Andrew Hill <dru treshna com>, gnucash-devel gnucash org, gnome-office-list gnome org, Tim Lord <timl treshna com>
- Subject: [gnome-db] Re: Abiword report generator [was Re: Dynamic data queries]
- Date: Mon, 8 Mar 2004 08:14:18 -0600
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 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.
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.
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.
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.
I hope this wasn't a too-simplistic restatement; after the last email,
I was concerned that there was some confusion.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas linas org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]