[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: DESIGN (was Re: koffice/kspread)
From:       Ariya Hidayat <ariya () kde ! org>
Date:       2004-09-17 13:46:23
Message-ID: 414AEAAF.4050708 () kde ! org
[Download RAW message or body]


> Hmmm... What will the *tree* be used for then? If I understand this
> correctly, then you're using the same trick that I've used in the
> dependency manager - you don't store information about each cell, but
> information about a bunch of ranges, each range being of the same size
> (say, 100 rows x 10 cols), and each range information containing
> formatting commands affecting cells in the particular range, be it one
> cell or more. So, if I change formatting of something really huge,
> then many ranges shall be affected. Is this correct?

Tree is used for fast range lookup. There is no need to split a range to 
a fixed-size range, you just need to tag that range into all nodes where 
the range covers. When you change some huge ranges, just those ranges 
area are affected.

Again, I'm still not 100% sure that a tree is The Right Way to go 
(although I'm convinced it will work). That's why I'm (re)searching for 
alternatives now. I'll post more when I have something new.

> Hmmm... Well, in any case, that recalc manager can be obtained simply
> by splitting the currently planned dep. manager in two parts, right?

Yes, but see now that the responsibilities of these managers differ. Of 
course the dependency manager must support the recalc manager, i.e. by 
supplying such service which allow recalc manager to "visit" all 
dependents of given cell (the "foreach" stuff, implementation-wise). 
Every manager still does its own job, but they communicate to each other.

Please note also that once recalc manager is established, we can do real 
recalculation like Microsoft Excel. For example, if A2 contains "=2*A1" 
and B2 contains "=RAND()", then when you change A1, not only A2 is 
recalculated but also B2 due to the volatile function RAND, though it's 
clear that B2 is not a dependent of A1.

> Anyhow, I've been thinking about that thing you wrote previously -
> that there must have been a reason for setting a CalcDirty flag in
> dependency calculation, instead of recalcing immediately. And I have a
> very good reason why we cannot do that, why we have to recalc
> immediately. Or, more precisely, you have that reason ;-P 
> Content-View separation... Currently, cells with CalcDirty are
> recalculated in makeLayout(), which however will reside in the View
> part... Hence, if you don't use View, but only Content, you'll never
> get any recalculation that way -> bad.

This needs to be changed then, recalculation should happen within the 
cell itself. The fact that the new "appearance" of that cell must be 
redisplayed to the user is the responsibility of the View.

> How many classes currently call begin/endOperation? Dozens. And how
> many classes will call disable/enableUpdates? One. Only one - the base
> manipulator. Actually, we could make it even without these *Updates
> methods - their "only" purpose will be to speed up things a bit... Or
> a lot... For if we update a A1:Z100 range, then everything using that
> range will be updated way too much times, cell damaging will be called
> lots of times, for each cell in the range. This is a waste of time.
> Hence, disable/enableUpdates will exist. Each manipulator (as it
> derives from BaseManipulator) will have access to some
> variable(attribute) - let's call it updateAtOnce. If it sets this
> variable (in its constructor, to be precise), then when we trigger
> this manipulator (via something like BaseManipulator::manipulate
> (RangeList rl)), manipulate method will call disableUpdates at the
> beginning, enableUpdates at the end, then it will call
> Sheet::rangeChanged (rl); There will probably be more such methods
> like rangeContentsChanged, rangeFormattingChanged and so on, to allow
> more fine-grained control over the whole process (using some other
> variables in BaseManipulator).

No need to damage each cell every now and then.
Suppose you create a command corresponding to the user action of making 
the background of a range to blue. Upon execute, the command will save 
the current formatting of those range for the undo, set that range to 
have blue background, and trigger a damage, i.e doc->addDamage( new 
RangeDamage( range ) ). One damage to rule them all...


Best regards,

Ariya Hidayat

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]