lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Enumerating open technical issues


From: Greg Chicares
Subject: [lmi] Enumerating open technical issues
Date: Wed, 15 Nov 2006 16:37:19 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

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 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 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?

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]