Re: GnuCash page on GO site



On Fri, Feb 27, 2004 at 04:56:53PM +1100, Martin Sevior was heard to remark:
> On Fri, 2004-02-27 at 02:57, Linas Vepstas wrote:
> > On Fri, Feb 27, 2004 at 01:43:18AM +1100, msevior physics unimelb edu au was heard to remark:
> > > 
> > > I wasn't suggesting this code be in AbiWord. I was meant that we could
> > > invent some fields that could be filled *explicitly* by GNUcash. AbiWord
> > > would call out to the external GNUcash program via a plugin to extract the
> > > values of the fields.
> > 
> > Yes,... 
> > I was thinking of a relationship similar to that between glade
> > and libglade.  In this analogy, abiword is like glade.  
> > 
> > glade                               abiword
> > -----                               ========
> > The GUI designer uses              The form designer uses
> > glade to design a gui.             abiword to create a form.
> > 
> > His GUI has a text box             She uses abiword to create
> > widget, and the name of            a dunning letter. "Dear sir,
> > that text box is "total"           you owe us (_total_) dollars.
> >                                    Sincerely, William Sue,esq."
> > 
> > C Programmer uses libglade          C programmer does ???
> > to access the GUI. Programmer       to push a value into 
> > does a GtkTextView *txt_w =         (_total_).
> > glade_xml_get_widget("total");
> > then does
> > gtk_textview_set_text(txt_w,
> > "$123.45"); 
> > to insert text into that widget.
> > 
> > Programmer does                    Programmer does ???
> > gtk_widget_show(txt_w);            to cause the resulting 
> > to make the GUI visible.           form letter to display/print.
> > 
> > 
> > The above is a "push" model where gnucash pushes data into
> > the form. 
> > 
> 
> I agree it's much easier to do this. We can certainly put hooks into
> AbiWord for this. There are many ways to set up the communication
> between GNUcash and AbiWord. Do you have a particular idea in mind? 

Well... I'm not sure what you mean. If the analogy to libglade holds,
then one needs C API routines that are analogous: for example:

void abi_form_init (void);
AbiForm *abi_form_open_document (char * filename);  
AbiFormField *abi_form_get_named_field (AbiForm *form, char *fieldname);
void abi_form_set_text (AbiFormField *field, char *contents);
void abi_form_show (AbiForm *form);

This would be enough to implement the example above.

It gets a little trickier to implement lists and tables, where 
for example, the number of items in the list are not known at the time
that the form document is being visually designed. 

The abiword gui needs to be modified so that the forms designer
can add named/tagged fields. I dunno, maybe this is already sort-of
there for the database access methods?

Then there's the question of "what does abi_form_show() do?".
Does it fork a new process and launch abi, or did
abi_form_open_document() do that?  Does it have to be a fork(),
or can it run as a library within my app?  If its a fork(),
then you need to keep a socket open so that you can send 
messages from abi_form_set_text() to the runing process... 
You need to decide how to do this, based on the current 
archtecture of abi.  All I care about is that startup is fast, 
layout is fast.

Next, there's the question of "what is the visual presentation?"
My gut instinct is that I would *not* want to have abi, with all 
of its menus, come up.  I just want the text displayed.  Just
the text window.  If the hypothetical "AbiForm" above was a 
gtk widget, that would even be better.  I'd like
to decorate this window with my own menus, containing entries
such as "print", "save as abiword document", "open in abi", 
"open template in abi".  This makes it clear to the user that they
are viewing the report, and if they really want to get the 
full editing capability, they can get to that, but really its 
just a viewer at first blush. 

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