Re: GRAND MASTER PLAN

[msevior physics unimelb edu au]

> On Tue, Mar 09, 2004 at 09:41:10PM +1100, msevior physics unimelb edu au
> was heard to remark:
>>
>> >> Forms creation.
>> >> I think we all seem pretty confident in glade here. thats solved.
>> >
>> > Uhh, forms and reports are two sides of the same coin.  Remember
>> > my 'bugzilla' analogy:  The bugzilla "report" for bug 123 is also
>> > a "form" that allows the user to modify bug 123.   I'd like to
>> > be able to embed widgets into abiword docs, and use libglade-like
>> > api's to find & work with those widgets.
>>
>> OK You don't mean literally "GtkWidgets"
>
> Well, for Act 1, you're right, I don't.  But for Act II ... yes,
> literally.  Pushbuttons, you name it.
>

Well this could be done too but I don't want to for a long time.

> Lets finish Act I first though.
>
>> >> Reporting
>> >>
>> >> reporting engine, what is gnomedbs requirements? Linas, maybe a gtk
>> >> output engine or a xml to gladexml converter, or use the existing
>> html
>> >
>> > Reporting is on the same coin as forms, its just on the other side.
>> > A "form" flows data from somewhere else to my application.
>> > A "report" flows data from my application to somewhere else.
>> >
>> > This is THE "high level" abstraction layer/API, to me.
>> >
>> > My app codes to this high-level API.  It then picks a particular
>> > driver.  There is one driver that will push data into an abiword
>> > doc.  There is another driver that will push data into a pane
>> > of gtk widgets. There is a third driver that will push data
>> > into xml.  There is a fourth driver that will pushd data into
>> > sql. A fifth driver will push data into ldap.  A sixth driver
>> > builds a web page and pushes it out to Apache. Etc.
>> >
>> > (My "DWI" project was my attempt to create this high-level API.
>> > I currently have drivers for glade/gtk and sql.)
>> >
>> > Its possible that gnomedb and/or libmergeant has this kind of
>> > ability, but if so, I haven't figured it out yet.  Its not
>> > clear how to create new drivers.
>> >
>> >> Report Designer.
>> >>
>> >> None of have anything here (expect gnue).  Its needed. I was thinking
>> >> orginally using openoffice or abiword to design reports but i really
>> >> havn't started looking at this at any detail. Any suggestions on how
>> we
>> >> are going to achive this? Does this sound feasible?
>> >
>> > I've been trying to explain to Martin Sevior what my vision for abi
>> > is, and I think he almost gets it. I thnk once he gets it, it will be
>> > easy.  I want abi to have a libglade-like interface.  The report
>> > designer creates a named text block, and my program can then change
>> > the text/color/font of the named text block.  I can't beleive this
>> > is going to be hard.
>> >
>>
>> You right :-) It isn't hard at all. It's one weeks work I think.
>>
>> The GUI is trvial. Simply select a region of a document, choose
>> "External
>> Source" from a menu, pop a simple dialog and ask for the unique name of
>> the property.
>>
>> The Property could just as easily be an input as an output. ie the
>> external app could look up the property and find the text with the
>> property. The input text could be used to modify what we want for
>> output.
>> We could also mark these properties as non-printable so they're removed
>> fromt he printed report.
>
> Bravo!
>
> OK, now that you've got this mastered: let me pile on a few things.
> For act I scene II:
>
> -- colors, font sizes.  At least for financial reports, negative
>    numbers are sometimes printed in red.  Of course, one won't know
>    if the number will be positive or negative until runtime, so the
>    color needs to be settable at runtime.
>

This is very easy.

>    (Yes, color alone is an accessibility issue; so other visual
>    indicators are used as well. (a simple minus sign is too small,
>    too easily confused for lint). Parens might be used, or
>    italics or bold might be selected.)
>
> -- might be useful to allow the "hide this" for visual display
>    as well. For example, the report designer created a document
>    with two blank fields,  and at runtime, we discover that one
>    of them will be blank forever.  So at run time, we hide it.
>
>    (I've seen this done in form letters, where certain geographies
>    get an extra sentance or two in thier form letter which the
>    others do not.  Another example is a report for assets and
>    liabilities: if there are no liabilities, you hide the table
>    rather than showing a table with a zero in it. )
>

We can do hidden text right now. I'm about to work on hiding text for
outlining and I think this could be extended to hide tables.

>    (If you can hide, then this allows the programmer to implement
>    a basic either/or: show/hide the liabilities table, and
>    show/hide the sentance: "There are no liabilities.")
>
> -- tables. Reports will usually have tables in them, and the number
>    of rows won't be known until runtime. (The columns are usually
>    static. Usually).
>

No problem here. Tables can be manipulated easily enough. Although we
might  want to make some convience functions so that the external program
doesn't have to jump through the hoops abiword would require normally.

(You have to insert the rows first then fill them with text afterwards.)

>    Tables might be nested.  I don't know if abi supports that.
>

Yes we support nested tables. AFAIK we're the only word processor apart
from MS Word that does. Neigther OOo nor Word Perfect does.

>
> Totally off-topic, but I thought I'd mention an unrelated feature:
> in financial reports, the tables are often presented as grade-school
> sums, with a bar between the bottom row (which contains the totals)
> and all the rows above it.  For nested sums, the bar may be a double
> or triple bar (to denote the grand total of subtotals).  ...
>

We could add an extra feature to allow specific rows or cells to have
extra decorations. The UI to elegantly present this feature would be a
pain though.

Maybe we won't ordinary users about this :-)


Martin