lmi
[Top][All Lists]
Advanced

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

Re: [lmi] calculation summary GUI


From: Evgeniy Tarassov
Subject: Re: [lmi] calculation summary GUI
Date: Thu, 9 Nov 2006 18:59:37 +0100

On 11/8/06, Greg Chicares <address@hidden> wrote:
On 2006-11-8 19:54 UTC, Boutin, Wendy wrote:
> Evgeniy Tarassov wrote:
>> 2) recalculating the "calculation summary" html output (the window
>> with the summary data in it) automatically when user changes
>> "calculation summary column selection" (File->Properties)?

The numbers won't change, and don't need to be recalculated.
It's sufficient to regenerate the html. IOW, I think the
'ledger_values_' member doesn't need to be updated, and I
guess 'ledger_formatter_' doesn't need updating either.

Yes, exactly. The only little annoyance could be the fact, that user
could select one of those heavy-calculation-time columns (IrrCsv_XXX,
IrrDb_XXX, that will trigger a call to
ledger_invariant_->CalculateIrrs(*this); -- on my mashine it takes
several seconds).

These columns and the cotly calculations needed where already discussed here:
http://lists.gnu.org/archive/html/lmi/2006-10/msg00031.html
and the conclusion was to not to call the function
(ledger_invariant_::CalculateIrrs) if the calculation summary columns
do not contain neither IrrCsv_XXX nor IrrDb_XXX.

I don't see no simple solution on how to cache the xml data and check
if it should be updated or not after a change to calculation summay
columns selection. The commit on 20061109T1742Z recreates the xml data
for every columns selection change, which could take seconds for every
opened window if the columns selection contains IrrCsv_XXX or
IrrDb_XXX columns.

To avoid the situation when the user is stuck at not-responding
application (which updates a large number of IllustrationView windows)
i have added a wxProgressDialog which at least shows the update
progress and notifies the user that update is in progress. I hope it
does not break lmi's GUI phylosophy.

> The second one: 2). After discussing this with Rick, who's
> discussed it with Greg too, I think there are a few details
> to consider. Notably, what to do if there are multiple
> calculation summaries open in the program.

Here's a naive, untested, off-the cuff idea, just to express what
I think is desired in something closer to solution-domain language.

Whenever you would already save the settings to file, do this too:

  for w in {all children of main frame window}
    if w's type is IllustrationView
      then w->DisplaySelectedValuesAsHtml()

That's brute force, but it doesn't seem too brutal. This comment
in 'view_ex.hpp':

Thank you for the tips! The changes to the code do exactly the same
thing you have described above.




reply via email to

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