[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-16 15:16:24
Message-ID: 4149AE48.7090901 () kde ! org
[Download RAW message or body]


> Yes, sure :) I can well imagine how the whole thing could work, the
> only thing that somehow doesn't "fit" into the overall picture is
> range formatting and that 4D tree. I cannot imagine how would you
> order the formatting commands, if they are wide-spread amongst many
> nodes of a tree, which obviously is ordered from bigger chunks down to
> small ones... What is you, say, set color of A1:D10 to green, then
> color of C8:F25 to yellow? These overlap a bit, hence you need to
> first break the green range formatting of the first part, then somehow
> set it for the second part, which probably won't fit into the tree
> quite nicely, hence the formatting is spread amongst multiple
> branches, brb. This opens up such a huge can of problems, that I
> really suggest not to worry about ranges and stay just with sheet's,
> columns', rows' and individual cells' formatting.

The quad-tree is used only for range lookup. Say, given a list of ranges 
and its attribute, you must find which ranges contain a certain cell. 
The easiest way is of course to iterate, check for each range, and if 
the specified cell isn't with this range, then skip it, otherwise 
proceed it. Speed-up if possible when we can know which ranges are close 
enough to that cell and potentially contain it. Thus, a tree is used. 
Think of this tree just like the BSP (binary space partition) used in 
computer graphics. And there is no need to split a range into two or 
more (if covered area is already small enough) because the node in such 
kind of tree doesn't mean the only range within the area, but any ranges 
which may contain one or more cells there. Tree construction isn't 
really related to the formatting piece, but to non-empty cells.

Of course any kind of other fast range lookup is also a candidate. To 
put simply, the main task of this range lookup system is to give a list 
of ranges which contains a specified cell. For your example above, I 
want to know which formatting range(s) affects cell C8, given that it 
stores A1:D10 as green and C8:F25 as yellow. I'm still researching which 
method is easier to code but still offers acceptable performance. As 
starting point, simple iteration will just do the job (albeit slow for 
complex case).

> Hm, we'll see... But I've already tried to modify a couple of things,
> and I ended up throwing most changes away - there are too many things
> being set at too many places - or maybe I just have some bad luck,
> shrug. But I'll keep trying... :D

Just discuss here, perhaps someone else could give some new ideas.

> Hm, CellWorkers are a bit too simple, at least from what I've seen so
> far. While they already provide some parts of what I want to achieve,
> I still think that they just aren't good enough. But maybe they could
> be used as a base for the manipulators stuff...

Please elaborate, which parts do you want to achieve which are not in 
CellWorkers yet?

> Brb, the command most certainly WON'T iterate over depending cells -
> it won't know that depending cells exist - and dependency manager
> won't know that commands exist... Commands won't know that repainting
> exists, repainting will just repaint and NOTHING more, and so...
> Encapsulation, see? ;) Current code often fails to hide implementation
> details into dedicated methods/objects, hence it's kinda hard to make
> changes. This needs to change, as everyone who reads my mails should
> know by now, hehe ;)))

I don't quite agree. Commands are part of the "View", hence it should 
know a bit about repainting. What else should be more responsible for 
repainting? Since repaint is only performed when a user takes an action 
(hence, the command), this is IMHO the right place to trigger damages.

Dependency manager doesn't need to know about command. It just needs to 
provide a service to iterate recursively over all dependents of given 
cell and do something (the "foreach" stuff).

A non-GUI tool which reads, accesses, or constructs KSpread document; 
for example  doing some data analysis (this could happend one day when 
KSpread is advanced enough); should not trigger thousands of damages, 
not only because no view is available, but most important is because it 
should access the spreadsheet object model directly (Document, Workbook, 
Sheet, Row, Column, Cell), not through commands.

If we want the real Doc/View architecture, then anything related to the 
"Doc" (e.g. cells, sheets) shouldn't know about the "View". Dependency 
management is part of the Doc, repainting and command are of the View, 
but we need to couple them together. For this purpose, I propose to 
trigger damage from within a command.

> Calc dirty? No. I'll recalculate'em directly. More efficient.

I'm sure there's some reason why this has been done that way. One 
possible thing is to avoid recalculating certain cell(s) twice or more.


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]