[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:24:59
Message-ID: 492258b10512170424s76507894yf7811f3be10a69ca () mail ! gmail ! com
[Download RAW message or body]

On 12/17/05, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote:
> Yes, and to modify the region you should use add(..) or sub(..) and don't
> touch the QValueList<Region::Element*> directly. That's what I meant.
> Further, the manipulators work on regions and to undo an opertion you need to
> know which cells were affected. You see we need the region. :)

Ah, so basically, you do it to make things run faster ?

> > 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.
>
> Fine with me.

So shall it be then. Does the basic Manipulator already use
begin/endOperation ? I could also look at the code, but this is faster
:P

> Yes, the MergeManipulator and DissociateManipulator are ready. Feel free to
> improve the basic Manipulator.
> I prefer to keep it general. So a manipulator working only on one cell I
> dislike. It should work on a region, which coul be also a single point.

Very well. I don't really care whether we get a manipulator over many
cells and also over one, or two of them - it's just that we can get
simpler API for the one-cell version - but we can put that into the
generic one too, so either works with me.

> > Also, I believe that all the Manipulators/CellWorkers should be moved
> > out of kspread_sheet.cc - that file is way too big even without having
> > them in.
>
> The manipulators themselves are all located in manipulator.cc|h. The
> CellWorkers should be replaced by Manipulators step by step.

Ah, I'd say, let's keep only the manipulators that we want to inherit
from in manipulator.h - other should go to something like
formatting_manipulators.* and somesuch. Not really a big issue, but it
makes navigating over code easier - IMHO more smaller files (and
correctly organized) are better than a couple of 200K+ ones.

> > Also, what about merging the code into main branch ? I think this was
> > your initial query on here - I think it all depends on whether we
> > believe that we'll be able to adjust everything to support the
> > range-list selections.
> There are some repainting regressions and I touched the code of the 'choosing'
> of cells, i.e. selection for formulas. Which needs some more attention. Also
> if you go over the dialogs, the operations should also work on non-continuous
> selections (NCS), if they do in directly choosing the operation. Think of
> border ops.

But that's simply one manipulator, right ? The inheritants from
Manipulator should be able to somehow let the rangelist-walk know if
they need to operate over individual cells or over ranges. Maybe it's
done already ? When this works, then the bordering manipulator can
simply work on the whole range at once, instead of walking over
individual cells. Or, alternately, pass the current-rectangular-range
parameter to the cell handler, so that it can figure out whether this
particular cell is at some border or not.

> > My opinion would be that we should merge with trunk. If we continue
> > changing stuff in the branch, then there will be little development
> > done on trunk, apart from bugfixes - and we have the 1.x stable
> > branches for that. The only problem is that it's possible that we
> > won't make it with all the updates necessary - so it might be
> > worthwhile to put all the user-visible parts into some #ifdef stuff -
> > so that if we don't manage to update the whole GUI to behave
> > consistently on non-cont. selections, we simply disable the
> > possibility of doing them in 1.5 - while still having the background
> > code prepared, so we can work further with having this.
>
> #ifdef'ing is too much effort, IMHO. If there is not much developing in trunk,
> it's even better. So the chance not to run into merging conflicts is much
> higher. So, I propose to let the NCS evolve in the branch and then, if we
> think we converted enough, we merge. We don't have to convert all operations
> to NCS as they work fine with the last selected range. So, I propose to solve
> the above mentioned issues and merge.

Hm, I mean, only #ifdef out the possibility to do so, not the whole
code - I think this would only affect the ability to press Ctrl to
select further regions, right ? The rest of the code can stay, it will
simply never get used.

Solving issues and merging sounds fine too, but we run into a
potential problem with some features not working over NCS when 1.5
approaches. We can think about it then, though.

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