Re: Abiword report generator [was Re: Dynamic data queries]

[linas linas org (Linas Vepstas)]

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
> abiword document. It hasn't been till now because we've had other fish to
> fry and there has been no demand. 

And, um, well, don't get the impression that I'm going to write 
a whizbang app that uses these new abiword features tommorrow,
because I'm already busy. But I think that there would be a number
of database apps especially the database report generators, 
that would enjoy having the nice sort of visual layout 
that abiword could provide.   So I think its important to 
have at least the academic conversation.

> Just to carlify something. By "live" document, do you mean something that
> automatically updates without user intervention or a document where a user
> clicks somewhere and sees the result in the application? I can imagine how
> to do both in AbiWord.

yes.  Lets focus on the implementation.  If there were a libabi that
was analogous to libglade, that allowed me to get a named element
out of an abi doc, and then change the text in that named element
(or change its color, or change its font size.. ) then I could 
write an application, using this libabi that featured "animated 
documents".

Let us suppose that my application was a javascript interpreter.
Then my app would allow users to write javascript which would 
result in animated abi documents.

So I'd say that the first step would be to have a way of
programmatically accessing named elements in an abiword doc.

> I'm coming to understand what you guys want and of course the difficulties
> of getting the intricate details right in a full-blown accounting program.

Ugh.  Right now, the way we do this 'named element' problem in
gnucash is with horrid hacked html-in-scheme-forms.  The scheme
forms spew out the data, packing it with html along the way, and
we use libgtkhtml to display the result to the user.  It is hard
to create custom reports (other than to change a logo, a footer
a header, but you can't control the layout at all).

I solved this problem in a different way in 'gnotime': I embed
scheme-in-html.  To create a custom report, the user only needs
to know how to edit html.  Thus they can design beutiful reports,
with the only limit being thier ability to master hand-written 
html.   These reports are stored as "ghtml" files on disk. 
Gnotime will open one of these files, grep for the embeded 
scheme in them, and execute that scheme.  Most of the scheme
is in the form of "print value of (project name)", although 
one can embed arbitrarily complex scheme.

This is also bad because (1) handwritten html is a stumbling block
(2) scheme is confusing for most people (3) If people ever started
mailing around and sharing ghtml files, theres a huge security hole, 
because one can embeded malicious code in there and gnotime will 
mindlessly execute it.  Shades of microsoft ... 

> OK I think I get the message. I think we can implement things like
> pull-down lists (via custom context menus) relatively easily in AbiWord.

Whoa. 
Step 1: allow user to create a named text block, and a libabi programmer
to find that text block, and alter the text inside it (optionally,
alter the font size/color in that text block).

Step 2: allow arbitrary gtk widgets to be embedded in arbitrary
locations in abi documents.  Allow the programmer to find those
embedded widgets using a libglade-like api.

step 2 is a lot harder ... 

> The glade file is used to construct a non-modal dialog that the user can
> use to update different parts of his form and generate a new report. So my
> idea is that along with an AbiWord report form, this glade file is
> transmitted from the back-end to the AbiWord client.

No no, you're thinking cgi-bin or something. Don't think cgi-bin
or client-server.  No one wants to send or receive glade files.  
Similarly, no one wants to send or receive abi documents (well, 
maybe they do, but that is completely unrelated to this conversation).

> able to change fields and generate new stuff via the GUI.

I really just want to be able to write a c program that can 
alter a text block in an abi document.  Let me be more precise: 
I want my c program to display an abi document which has text
blocks in it, then have my c program change some text in that 
document, which is then instantly and immediately redisplayed, 
with a minimum of screen flicker and delay. 

So for example, there could be an abi document that looked
like "the time now is XXX" and my c program would display 
this document, and it would replace "XXX" by some other string
of the same length every few seconds, and there would be no 
flickering, and at most an imperceptible redraw.

I do *not* want to generate a whole lotta xml and save it 
to a file or pipe it anywhere or send or receive it or anything
like that.  I most certainly do not want to edit the file
containing the XXX, replace the XXX with some asci string, 
and  pipe that file to abi to redisplay.  I do *not* want to 
do that.

--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