[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-17 20:24:10
Message-ID: 414B47EA.2070703 () kde ! org
[Download RAW message or body]


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

> 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

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

> So I cannot simply call myVeryOwnCell->setValue (7); and let the
> redrawing magic happen? Shall I need to use commands, even if I don't
> want to? Shall I need to have two separate things doing almost the
> same, each being on one part? Dependency updater that will trigger
> recalc of each cell [which HAS to be in the "Doc" if we want to be
> able to use the "Doc" without the "View"), and yet another updater in
> the "View" that would update damages? Each of them rtiggered in
> another place? Brb, I don't like that.

Doc/View isn't always lovely.

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.


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]