[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 19:30:25
Message-ID: 414B3B51.1000408 () kde ! org
[Download RAW message or body]


> Hm, I'm still not 100% sure either... It still looks like it will
> cause more troubles than it's worth... But we'll see...

Perhaps, but at that time, tree like this was the only scalable solution 
I could see. Now I have more ideas and would like to explore them first.

> Hmmm... *loading excel in wine...* Oh, indeed... Hm, is it really a
> good idea to recalc random() whenever someone changes some cell on the
> other end of the spreadsheet? Alright then, we'll have a separate
> recalc manager. However, this almost looks like duplicate work between
> these managers and manipulators. Hence we might need to implement at
> least basic manipulators support first. Hm, but these need some bits
> of cell damaging. Damn, my head hurts. Argh. Alright, duplicate work,
> here I am...

In the end, recalc manager takes more headache than depedency manager, 
because it is the actual workhorse. Of course, for provisory purpose, we 
can build a simple one and verify the concept first.

> Sure, but that's just a special case. You can set a color of a range
> (if we really have those range formatting thingies), but you can't use
> this for auto-fill or sequence fill or paste or who-knows-what-else.

Why not? Given than the dependency manager (or recalc manager) provides 
a service to iterate over dependents, then it's again a matter of 
"foreach" operation, collect cells affected by the command, and trigger 
for example a RangeList damage. AFAICS this is how Gnumeric does to some 
extent (note also how Gnumeric's cell_content_changed is gone when they 
have much proper dependency handling).

> In addition, do you really want it, so that each manipulator calls a
> cell damage? That's extra work, which really isn't needed, hence we
> must avoid it. Simpler code = better code. In addition, we're more
> likely to get more people working on KSpread if it's really easy to
> add a new feature...

I didn't write that "each manipulator calls a cell damage". What I 
propose was even the opposite, right in the end of ::execute() of the 
command, trigger only one damage (quite possibly RangeDamage) for all 
the affected range(s).

I might want to distinguish clearly the difference between 
CellWorker/Manipulator and Command. The former is part of the "Doc", the 
latter is the "View". You have commands because the user takes some 
actions, nothing more nothing less. Triggering a damage is the 
responsibility of the View, so it should be in the command.


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]