Abiword report generator [was Re: Dynamic data queries]

[msevior at physics.unimelb.edu.au]

> On Fri, Mar 05, 2004 at 03:04:15PM +1300, Dru was heard to remark:
>> openoffice.org - ms office copy cat approach. I dont see open office
>> team been able to easily create a ms access replacement and i'd prefer
>> them to improve other parts of openoffice.
>
> A couple of remarks:
> -- MS look-alike can be a big mistake. For example, I like eveolution,
>    but they managed to copy some real cruddy parts, like the to-do list.
>    Parts that MS itself will no-doubt ditch in the next version ...
>
> MS Access has some serious problems that should not be copied. There
> are high-end apps from e.g. Oracle that work much more nicely than
> MS Access.  There is also Lotus Notes.
>
>> Ie. dwi, bond and gnomedb use glade as a common forms designer while
>
> The Lotus Notes forms designer is like a smash-up between AbiWord and
> Glade. You can place any button, widget, etc. anywhere in a document
> that has arbitrary text formatting, margins, fonts, etc.  Today,
> we have this kind of ability in HTML (you can place an HTML FROM
> anywhere on a web page; hell you can even use javascript in a web
> page) but we still don't have that in abiword.
>
> (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. However I personally really like the
idea of developing synergy between projects. Combining experiences from
different  fields is how 90% of innovation happens.

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.

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.


> The point is that these emails were live documents, and the buttons
> were live, and they were connected to a remote database somwehere,
> where user responses were tallied.  We're not there yet.
>
>> maybe sharing same reporting engine will also
>> help all the projects along.
>
> I'm concerned about the idea that the report generator is somehow
> an off-line batch processor.  Take a look at the gnomedb report
> generator: it creates XML, good lord! With header and footer and
> colors! I'm sorry, but that is sooo wrong.
>
> Reports need to be thought of as the other half of forms.  A "form"
> is a document where the use is queried for info.  For example,
> the google home page is a "form".  A "report" is how data returned
> from the database is presented to the user. For example, the
> result of a google search is a "report".
>
> Sometimes, "reports" are visually merged with "forms".  For example,
> suppose you search for bugzilla bug 123.   You see a "report" of bug
> 123, but that "report" is also a "form" which allows you to make
> modifications to bug 123.
>
> My point being that you could never build something like bugzilla
> from the the gnomedb report generator (and if I'm wrong, then
> I grossly misunderstand the gnomedb reports).  The output of
> a report generator must be targeted to the same interface as
> the forms designer.  In the case of dwi (and bond), this target
> is the glade widgets, although I argue here that it should also
> be a live AbiWord document.  A report that is a static
> post-processed Abiword document is useless.
>

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.
I'll think more about what would be the best way to present a user
interface for a  live report. I'm thinking along the lines of a glade file
connecting GUI feedback elements to the text on the screen in the
document.

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.

The advantage of doing things via a seperate GUI is that a user can have
the final say about tweaking things in a WYSIWYG document but is still
able to change fields and generate new stuff via the GUI.

Is this along the lines of your vision?

Cheers,

Martin
> --
> 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
> _______________________________________________
> gnome-office-list mailing list
> gnome-office-list at gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-office-list
>