On Thu, March 29, 2007 3:16 pm, two old wrote: > First I agree a script should output content to a HTML template. The > template would secure the way my invoices or reports look on every update > of GnuCash or even an update of the script.
There's a separate set of concerns about customizing reports. If we install a revised report as a script + template, and you customize the template in the install location, it'll still get over-written at upgrade time. There are use-cases for both customizing only the template, and more so customizing the whole report (and likely the template). In my experience -- particuarly: customizing bugzilla both before and after they introduced explicit UI templates -- it can be almost as hard either way. Effort is required to revise a report in a way that customized templates are guaranteed to work going forward. Most likely, one wants to enhance the report, and thus the template, which will to some degree invalidate the customized templates as well. It's a pretty standard problem, so I'm not sure that we should do anything more than make it: a/ easier to customize the reports and templates, b/ encourage those customizations to be conditional/config-driven and c/ encourage contribution and thus our re-distribution. Basically: remove the reasons why individuals users need to have a customized/non-installed report that can be overwritten or invalidated. > If we can make a script that put content into a HTML template and then > launch a web-browser to view and/or print it, this would be a huge step > forward. That's an interesting idea ... I'm not sure that it's the best user experience, though, in terms of the interactive refinement of the standard reports... where you change the date range, change the graph parameters, and don't really want to see another spawned browser instance. Moreover, we do support hyperlinking strings (and historically plot/graph elements) with other GnuCash interface elements like accounts registers and customers. In that case, you even more so want the browser embedded for practical/integration concerns. But if we do embed or use a browser component to which we can offload most of the heavy lifting of printing, we should leverage that. > Besides that, step one can be developed without interfering with the > printing libraries as they are now. I think ........... The printing libraries are changing, so we do need to modify gnucash's use of them to stay "current" with our dependent libraries. The reports are the major consumer of printing services in GnuCash, but there are others. > So first of all I'm looking for an understanding of how this > printing/reporting/scripting business essentially works. I understand C > but I know nothing of Scheme. Nevertheless maybe I can make a start For the existing code, there is some documentation in the source tree; in short... The report (a scheme script) is evaluated; it calls on the gnucash-provided reporting system to install itself into the report list and menu. When the menu item is invoked, a report-defined callback is called to generate a (html) document, which is then rendered in the gnc-plugin-page-report window, using gtkhtml. The report also defines an operation generator (another callback function), which is used to create the report options UI; when Apply (or Ok) is pressed in the options dialog, the old document is thrown away and the report's rendering callback is re-run. -- ...jsled http://asynchronous.org/ _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
