[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: kspread: non-contiguous selection
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2005-12-17 12:32:24
Message-ID: 492258b10512170432y64319f11me640cb4c7ed826e0 () mail ! gmail ! com
[Download RAW message or body]

On 12/17/05, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote:
> On Saturday, 17. December 2005 12:24, Tomas Mecir wrote:
> > I assume that the Manipulator class makes internal use of the
> > emitBeginOperation/emitEndOperation ? Ultimately, I'd like to have it
> > so that every and each function which currently uses these two, will
> > be adjusted to do its work using some manipulator instead. That way,
> > it will be trivial later on to port things to Ariya's damage-based
> > concept - we'll only have to port Manipulator, the rest will simply
> > stay as it is.
>
> Reverting my last comment.
> Canvas::slotScrollHorz() don't need to be a manipulator and there are more of
> those. Let's agree, that each operation on cell regions should become a
> manipulators. The others not. Okay?

Yeah, it's not so obvious on things that simply move the cursor/view
around (are these the only ones affected?).
These indeed don't need to be manipulators, but at the very least,
they should be somehow merged together, so that we only have ONE
view-moving code, and only ONE cursor moving code - I think there's
some duplication as of now.

Hence, we only get two more cases where emitBeginOperation and
emitEndOperation are used. I want to keep occurences of this to the
minimums, to make it easier to get rid of them when the time comes.

/ Tomas
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]