[Libreoffice-ux-advise] new range name dialog proposal

[Christoph Noack]

Hi Kohei, hi all!

Am Dienstag, den 25.10.2011, 20:40 -0400 schrieb Kohei Yoshida:
> Hi Christoph,
> 
> Just one thing to consider regarding the performance impact of the
> proposed change...

Of course ...

> On Tue, 2011-10-25 at 23:26 +0200, Christoph Noack wrote:
> 
> > Yep, would be one solution ... maybe we do some nasty tricks to make the
> > user believe it is a character-by-character update?
> >       * When changing a name / expression (e.g. entering a character),
> >         the system might check for the name / expression validity, and
> >         (if valid) update the table. The model stays unchanged. If the
> >         name / expression is invalid, further changes in the model
> >         mustn't be done anyway.
> >       * If the user exits the input field, then the model is updated and
> >         a undo item is created.
> > 
> > But still, I don't know whether its doable or solves the performance
> > issue. But I really think its very elegant ;-)
> 
> I agree that it would be an elegant solution.  However...
> 
> One issue we need to consider is that, once the name is updated in the
> model, and assuming that the auto recalculation is turned on (it's on by
> default and most users leave this on), all affected formula cells will
> need to be re-calculated.  And this needs to happens every time a name
> is updated.  Depending on how large the document is, and how complex its
> formula network is, this can be very expensive.
> 
> Right now, all modified names are committed to the model once when you
> click OK, so at most we have to re-calculate once.  But if the current
> proposal becomes implemented, then we would need to do re-calc on every
> name definition change.  That would potentially make the whole name
> updating experience unpleasant.
> 
> If the dialog was modal, we could temporarily turn off auto-recalc and
> turn it back on once the dialog is dismissed, but we can't do that with
> modeless dialog.
> 
> Sorry to give you guys another obstacle.  But I felt I needed to mention
> this to make sure this issue is taken into consideration in the design.

Of course, thank you ... you also pointed towards another issue I wasn't
aware about - but that's another story.

Coming back towards the issue of "performance", what's the impact we
talk about? Markus once mentioned that you have a file with approx. 600
range names ... maybe you have some files that already cover even more
range names incl. complex calculations.

In such a case, what's the impact we talk about? I simply don't have a
clue ... it could be 100 ms ... 10 seconds per update on an average PC
(whatever average means). Would it be possible to get such a file?

Cheers,
Christoph