So basically we need a script that keeps all options open: if custom script exist -> execute ([user dir]/script) else use standard script.
if custom template exist -> use it ([user dir]/template) else use standard template Fill template with data switch (option-browser) case internal browser: case external browser: The option-browser can be a selection the user can make. I agree we do not want to launch an external browser if we are navigating the accounts. But for reports/invoices it may be an acceptable alternative. And in time when the internal browser gets better the option external browser will not be used anymore. Maybe the script will have to rip some style tags for the template if the browser of choice is internal. I don't know I'm not familiar with the capabilities of the internal browser. There can even be an option in the configuration use standard or use custom if the user wants to see the effect of the standard script/template. With all the individuals on this world removing the reasons why individuals users need to have a customized/non-installed report is in my opinion an idle hope. In my opinion the individuals will customize the script/template, this is a fact. Therefor you have to define the restrictions rather then program for every eventuality. Sun Tzu (the art of war) said: Do not trust on the enemy not attacking but be prepared to encounter him. ----- Original Message ----- From: "Josh Sled" To: "two old" Subject: Re: New reporting system (Re: Again font size when printing) Date: Thu, 29 Mar 2007 17:17:11 -0400 (EDT) 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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
