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

List:       koffice-devel
Subject:    Re: kspread: non-contiguous selection
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2005-12-17 13:06:06
Message-ID: 200512171406.09049.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday, 17. December 2005 13:24, Tomas Mecir wrote:
> > > 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.

I've implemented a BorderManipulator some time ago, but it's not ready yet, 
e.g. no undo yet. That was before inheriting the Manipulator from KCommand to 
integrate the undo functionality.

The problem is, that applying the changes in the CellFormatDialog need a 
MacroCommand, because it applies all the changes made in the dialog. We have 
to convert all operations used in the CellFormatDialog to Manipulators to be 
consistent. And this should be done before the merge. Other operations could 
follow after the 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.

Ah, sure! This is possible. I'll put it in.

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

I don't understand. You mean the #ifdefs should go in, the mentioned issues 
have to be solve and then merge? Right?

Bye,
Stefan




[Attachment #5 (application/pgp-signature)]

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