RE: [lmi] Enumerating open technical issues

[Boutin, Wendy]

[I'd like to keep the whole context intact for completeness
sake, so I'm adding just a few things inline]

Greg Chicares wrote:
> All originally-planned work on the calculation summary has been
> finished. There are some open technical issues, none of which
> affects users, but which we need to make sure we cover. I'm sure
> I don't have a complete list yet, so let me pose some questions:
>  - What have we broken that used to work?

   - What have we lost that used to exist?

>  - What have we done that should be undone?
>  - What have we left incomplete?
>  - What have we left undone?
>  - What else could we now achieve with little effort?
> along with my partial answers, and ask others to add further
> answers or questions.
> 
> - What have we broken that used to work?
> 
> Building with como. I know a way to fix this, though.
> 
> Compatibility with xmlwrapp--but see below.
> 

   - What have we lost that used to exist?

Penny precision in the calculation summary column values.

> - What have we done that should be undone?
> 
> I think I mistakenly overconstrained this problem:
> 
>   http://lists.gnu.org/archive/html/lmi/2006-11/msg00023.html
> |
> | I could imagine someone seriously writing this:
> |
> |   <!-- All '.xs?' files belong in this directory. -->
> |   <xslt_directory>/etc/custom/xslt/dir</xslt_directory>
> |   <!-- Specify the customary extension for your spreadsheet. -->
> |   <spreadsheet_file_extension>.ss</spreadsheet_file_extension>
> 
> Sure, one might write that, perhaps in a file that warns, e.g.,
>   GENERATED FILE, DO NOT EDIT
> but to expect comments and duplicate elements to be preserved
> when settings are changed in a GUI and then saved seems now like
> too much to demand of an xml configuration file. Trying to do it
> makes the code more complex, and the format of missing elements
> that get added isn't as nice as it could be. Instead of refining
> that code, I think we should remove the constraint; then the
> (replacement) code becomes trivial. Normal users shouldn't care
> how the file looks--the GUI makes that unnecessary--and comments
> such as
>   Specify the customary extension for your spreadsheet
> should be help elements in an '.xrc' file.
> 
> - What have we left incomplete?

The bulk of this project can be summarized in the support tracker
item: https://savannah.nongnu.org/support/?105591 , but there's one
last thing to do:
 | Let's make sure we address the "-,100%" problem described here: 
 | 
 | 
http://cvs.savannah.gnu.org/viewcvs/lmi/lmi/ledger_text_formats.cpp?r1=1.21&r2=1.22
 
 | 
 | 
 | https://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=13856 
 | 
 | 
 | e.g., by using the same format routine for this task. 

before we can officially close it.
 
> Choosing a C++ xml library. I haven't yet had time to reply to
> others' thoughtful postings.
> 
> Code review. I doubt you've had a chance to look at the porting
> work I did over the weekend. Some 'CALCULATION_SUMMARY' markers
> remain in the code; Evgeniy has discussed a couple of them today
> on the mailing list, but I haven't had time to follow up.
> 
> - What have we left undone?
> 
> Reworking our use of xsl-fo. I believe we've laid the groundwork
> for this future project already, which will enable us to remove
> a great deal of old code before long.
> 
> Making formats configurable, by replacing the small handful of
> hardcoded formats with {number-of-decimals, [% | bp]}.
> 
> Porting: I think I've moved substantially everything to MAIN
> except for 'xml_resources_test.cpp' (it didn't seem to pass all
> tests in the branch, and I don't know why) and the new xml files
> (I'd like to find more-descriptive names first). But I may have
> missed something else.
> 
> - What else could we now achieve with little effort?
> 
> Edit all configurable settings in the new GUI. Not everything in
> 'configurable_settings.xml' really should be user-configurable.
> And class configurable_settings wants to be subsumed into class
> PreferencesModel.

---------------------------------------------------------
This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 

---------------------------------------------------------