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

List:       koffice-devel
Subject:    Re: DESIGN (was Re: koffice/kspread)
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2004-09-17 18:19:25
Message-ID: 492258b1040917111929c680f1 () mail ! gmail ! com
[Download RAW message or body]

On Fri, 17 Sep 2004 15:46:23 +0200, Ariya Hidayat <ariya@kde.org> wrote:
> > 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.

Hm, I'm still not 100% sure either... It still looks like it will
cause more troubles than it's worth... But we'll see...

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

Hmmm... *loading excel in wine...* Oh, indeed... Hm, is it really a
good idea to recalc random() whenever someone changes some cell on the
other end of the spreadsheet? Alright then, we'll have a separate
recalc manager. However, this almost looks like duplicate work between
these managers and manipulators. Hence we might need to implement at
least basic manipulators support first. Hm, but these need some bits
of cell damaging. Damn, my head hurts. Argh. Alright, duplicate work,
here I am...

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

Sure, but that's just a special case. You can set a color of a range
(if we really have those range formatting thingies), but you can't use
this for auto-fill or sequence fill or paste or who-knows-what-else.
Hence, we need something like this. And I'm 100% sure that I can
implement it properly, and that it will work properly and
transparently to all other classes.

In addition, do you really want it, so that each manipulator calls a
cell damage? That's extra work, which really isn't needed, hence we
must avoid it. Simpler code = better code. In addition, we're more
likely to get more people working on KSpread if it's really easy to
add a new feature...

/ Tomas
_______________________________________________
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]