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 _______________________________________________ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
