[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-18 16:57:09
Message-ID: 492258b104091809574768223a () mail ! gmail ! com
[Download RAW message or body]

On Fri, 17 Sep 2004 22:24:10 +0200, Ariya Hidayat <ariya@kde.org> wrote:
> 
> > Hm, who will trigger it? Each command? I hope not. Copy/pasting the
> > foreach stuff to each command is a no-no for me, so I really hope that
> > I've misunderstood this one.
> Implementation-wise, of course you can provide helper function to do so.

Alright then :D

> > Cell_content_changed disappearing from gnumeric... hmm... what were
> > they using it for? Why do they want to get rid of it? In my opinion,
> > it's a good thing to allow both trivial one-cell change, as well as
> > changing of whole ranges (when we disable reacting upon calling of
> > it).
> 
> Just track its source code and compare the revisions. Gnumeric ChangeLog
> is also very complete and useful. Believe me, it's a wonderful
> experience :-P

Mmmm, will have a look.

> > In the end of ::execute? So each command will need to call that in
> > order to work properly? No-no, there has to be some exec method in a
> > base command or somewhat that will call it after it calls some
> > doThings virtual method - hence the calling code exists only ONCE.
> 
> This is a matter of implementation. Formatting-related commands for
> example are simpler because they can exclude the dependents in the
> damage ranges. A helper function which does the foreach in the base
> command would be more enough (to be called by each command). Note also
> that there are sheet commands, say for inserting or deleting a sheet.
> Such commands may trigger a different kind of damages, so damage
> triggering from the base command only can't work.
> 
> I don't see a problem why each command should not trigger a damage by
> itself. Every command is unique and it has different damage requirement
> anyway.

Well... most commands modify cell content and/or formatting. Very few
commands are different. Only a couple of sheet commands, and these can
be handled separately, as manipulators (or CellWorkers if you prefer)
aren't really suitable for them.

> If everything is implemented properly, any user actions will have the
> corresponding commands (we need this for undo feature and
> if-any-volunteer-want-to-do revisions support). So the only place you
> would call myVeryOwnCell->setValue(7) is inside a command (DCOP calls
> and/or other script bindings are different story, need special handling
> e.g. proxied through commands).
> 
> Technically, the trigger for recalculation and for repainting need not
> be the same. But it is just happened that they use both the (shared)
> dependency manager (of course, with respect to type of command that
> queues the repaint) to do the jobs. You can even invent a very dumb
> command, just trigger a whole SheetDamage or WorkbookDamage regardless
> what ranges have been modified.

Why should repainting use the dependency manager? Recalc triggers a
cell damage, and that's about it, right? No need for the repainter to
know about dependencies and stuff...

Alright then, let it be this way. It's not really that much different
from my proposal after all, just a bit more work... Oh well, it might
be worth it.

What concerns recalc/dep manager, I'm going to put recalc into dep mgr
at first, so that it can be brought to life as soon as possible, and
when everything works correctly, I'll separate out the recalc manager
(no optimizations there yet, though, just a stupid recursive
recalculator).
But we'll need to resolve that name->index converting problem first, I
hope you got my mail about that...

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