[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 12:42:18
Message-ID: 200512171342.21965.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

At least the add() method looks, if the region already contains the 
range/point. And I want to save memory. ;)

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

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

Okay.

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

Okay, but reverse the naming in order for faster finding these ones, i.e. 
manipulator_formatting.h. IMHO we could do this later with the 
ManipulatorManger, which already exists in some extend. ;-)

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]