Re: GRAND MASTER PLAN

On Sun, 2004-03-07 at 14:42, [email protected] wrote:
> > Reporting
> >
> > I think we definetly need a common ground here or not write our own.
> > Unforuntly i already wrote my own, papyrus (stealing ideas from gnomedb)
> > when there was nothing providing reporting, now there are dozens of
> > reporting solutions out there (half are java/html though).  Linas, i
> > know how reports are done in gnucash and they are dynamic. A reporting
> > system should generate pdfs,ps,xml,html etc. And use the database low
> > level abstraction library. Can gnomedb people use papyrus or another
> > reporting engine, what is gnomedbs requirements? Linas, maybe a gtk
> > output engine or a xml to gladexml converter, or use the existing html
> > output engine to allow you to embedded report into a gui before
> > preview/print?  Would you consider xml approach?
> > Can gnome-db provide a highlevel reporting gui? One where you can run
> > reports, it asks for arguments for the reports and excutes the report?
> > Or where you can type an sql statement and it will put results into a
> > report.  Think mergeant reporting.
> > Can gnumeric/abiword provide mail merge features from xml report?
> >
> 
> AbiWord can do mailmerge right now. With a bit of hacking we can support
> live database feeds. I've just openned discussions with Rodrigo about
> these on this list.
> 
> With a bit more hacking we support direct feeds into defined locations in
> the document from an external source. Ie the source "pushes" data into
> defined location. But for this we need a clear idea of how to securely
> make the connection.
> 
> > After a quick look here is the different reporting libraries i found.
> > If you know of others that work well suggest them.
> > http://rlib.sicompos.com/
> > (havn't looked into in detail)
> > http://papyrus.treshna.com/
> > (lacks chart and editable content but is mature)
> >
> 
> Making editable reports is *far* harder than generating them. I suggest
> you look at either Conglomerate or AbiWord. I think Conglomerate could be
> a good fit to papyrus.

I agree; thanks for the pointer, I just added them as enhancement
requests for Conglomerate to Bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=136472
(Papyrus)

http://bugzilla.gnome.org/show_bug.cgi?id=136475
(Rlib)


Unfortunately the Papyrus XML format seems to lack both a namespace and
a DTD, which makes it trickier to support within Conglomerate (it has to
try and guess what XML doctype it's looking at).  But it's still
possible.

> 
> Jody has just about liberated the Gnumeric charting package into
> libgnomeoffice so it makes sense to use that.
> 
> I don't know if it makes sense sense to reuse all the  powerful numeric
> and statistical features inside Gnumeric. From the outside there appears
> to be the potential for signficant overlap.
> 
> > 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?
> >
> 
> Either AbiWord or Conglomerate. I think Conglomerate is a good fit for
> what papyrus is now. AbiWord would be quite a radical depature and the
> document would be constructed "live" straight from the template. From
> there we can export it to any one of your chosen file formats
> (ps,pdf,latex,html) plus a whole lot more.

I agree, looks like a good fit, though ideally I'd want to make some
changes to the details of Papyrus' XML format.  It also doesn't seem to
leverage XSLT; perhaps this could be used to add output->AbiWord and
output->OO.org etc.

Within Conglomerate we could have support for editing Papyrus XML files,
and a "Generate Report" option in the menus; these would be fairly easy
to add using a plugin (maybe a 1 hour job for someone who knows our
code?).

I don't really care about what database abstraction layer is in use etc,
I just want a sane XML format that describes how to generate the report,
ideally some kind of standardised one supported by multiple projects.

I'm not really a "database person", though so this stuff is low-priority
for me, I'm afraid.  But I'll happily accept patches :-)


> 
> > The Politics.
> >
> > Do we all fall under gnomes ? We have to at some point stop focusing on
> > these low level tools and start making some real applications. And know
> > where to share code where we can.  Maybe have a common organisational
> > group we can all belong to with links to our sites with, like gnome
> > office and list what we each work on? so we know what each other is up
> > to and have a common banner to achieve our vison.  I would in a way like
> > one day to have a website we we list a whole lot of database
> > applications for gnome.
> >
> 
> 
> I agree on the need to focus on complex application. It has been hard in
> general to attract hackers to complex projects. Given that the group doing
> Gnome-Office has self-selected into working on complex-apps, I think it is
>  best to put database apps under the the Gnome_office banner. We can cross
> fertilize and use our GUI apps in ways not usually thought of. I see the
> possibilities for code sharing and genuinely innovative features from the
> marriage of our strengths.
> 
> Martin
> 
> _______________________________________________
> gnome-office-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-office-list
-- 
David Malcolm
www.conglomerate.org