[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 13:19:12
Message-ID: 492258b10512170519v1e01eac6v6d4768194e5dd412 () mail ! gmail ! com
[Download RAW message or body]

On 12/17/05, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote:
> On Saturday, 17. December 2005 13:24, Tomas Mecir wrote:
> > > 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.

MacroCommand ? What is that ?
Can't we simply get one big manipulator that will handle all the cell
formatting ? I'm not quite sure whether this is such a good idea - but
after all, why not ? We could then use this manipulator in all the
shortcuts (toolbar and such).

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

Great ! :)

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

Yes. If I understand things correctly, then this is the best way to go.
The problem with features not  working with NCS can be then solved
using that simple #ifdef, so we'll be free to convert things on the
trunk, and the code will be also usable for 1.5, even if we decide not
to enable the Ctrl-select there - we just need to ensure that
everything works well for non-split regions.

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