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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
