[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-16 16:03:31
Message-ID: 492258b104091609035307c7c4 () mail ! gmail ! com
[Download RAW message or body]

On Thu, 16 Sep 2004 17:16:24 +0200, Ariya Hidayat <ariya@kde.org> wrote:
> 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, 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?

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

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

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

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

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.

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