[gnome-db] Re: GRAND MASTER PLAN
- From: msevior physics unimelb edu au
- To: "Dru" <andru treshna com>
- Cc: "Linas Vepstas" <linas linas org>, msevior physics unimelb edu au, gnome-db-list gnome org, "Charles Goodwin" <charlie xwt org>, gnucash-devel gnucash org, gnome-office-list gnome org, "Tim Lord" <timl treshna com>
- Subject: [gnome-db] Re: GRAND MASTER PLAN
- Date: Mon, 8 Mar 2004 01:42:37 +1100 (EST)
> 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.
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.
> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]