[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 17:25:49
Message-ID: 4149CC9D.4080304 () kde ! org
[Download RAW message or body]


> Hm, so in that case, how does it know which formatting is the one to
> use for C8? Should be (heavens forbid) store timestamps with each
> formatting command or what?

No, the depth of the range decides it (that's why I named it as 3-D 
format storage). If you set A1:D10 to green, and later on set C8:F25 to 
yellow, then C8:F25 is the topmost formatting piece which hits cell C8. 
This is because both range attributes are about color. Say, now you 
format A1:Z1000 as "bold" (formatting piece about font), then C8 becomes 
"bold" and "yellow".

> Well... Support for operating on a whole row/column, range lists
> (CTRL-selections), possibility to use a manipulator without #including
> its class, ability to set formatting, anything I may have forgotten...

- CellWorkers now also works for row and column, despite its name.
- Adding support for range lists is a matter of new function which 
iterates over the ranges there.
- Using manipulator without including class is a matter of inventing a 
sort of trader for those workers.
- Formatting? CellWorkers also support that, I believe.

> Why? The only thing that we need dependencies for is cell calculation.
> Dependency manager can to it itself... No need to rely on external
> class, or worse, to let each class to it separately.

Well, the name is dependency manager, not recalc manager :-P
Microsoft Excel even has problem with very complex sheet, although its 
dependency manager is (or must be) excellent. The job of dependency 
manager should be only limited to give information what depends on what 
(and vice versa).

We may then need a separate Recalculation Manager. It's clear, though, 
that this new manager relies heavily on dependency manager. But note 
also that not only a change in value or formula should trigger 
recalculation, but also for example a change in area name or formula 
such as RAND. http://www.decisionmodels.com/ may give some hints and 
ideas about this.

> Indeed. But triggering damage and knowing about damages/repainting are
> two separate things... Commands will know that there exist methods
> like valueChanged and formattingChanged, and that there is
> disable/enableUpdates in Sheet object (or more precisely, the base
> manipulator, that all commands will be inheriting from, knows that).
> These methods will trigger repainting, dependency recalc and whatnot.

I'm confused. To trigger damage you must know which cells, rows, 
columns, or charts are damaged, right? My proposal was that the 
responsibility of knowing which must be damaged should not be in the 
cell, because cell handles data, not view. To make it even more strict 
(of course after another hundreds of clean-up), Document, Sheet, and all 
such classes in the part of "Document" should not know anything about 
repainting and other "View"-related stuff.

OTOH I have the feeling that disable/enableUpdates will lead to the same 
trap as begin/endOperation. I hope I'm wrong.


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]