[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 11:54:17
Message-ID: 200512171254.20980.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday, 17. December 2005 12:24, Tomas Mecir wrote:
> On 12/16/05, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote:
> > On Friday, 16. December 2005 17:55, Tomas Mecir wrote:
> > > On 12/16/05, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote:
> > > > On Friday, 16. December 2005 17:23, Tomas Mecir wrote:
> > > > > Hmm ...
> > > > > class Manipulator : public Region
> > > > > Interesting inheritance that :)
> > > >
> > > > I plan to also inherit KCommand.
> > >
> > > KCommand is ok, but why inherit from a range ?
> >
> > Because, modifications of the region should not be publicly available in
> > general. First, I put the Manipulator as friend in, but if you derive
> > from Manipulator you're not more a friend. :(
>
> Modifications of the region ? What is that ? I was under impression
> that the Region class only stores coordinates and nothing more ?

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

> I'll have a closer look at things there - looks like I'll have some
> time for further KOffice-related hacking around xmas, so I reckon I'll
> go porting some more code to the Manipulator stuff, now that we have
> it :)

Yeah, this sounds great!

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

> Did you already write some manipulators, apart from updating the
> CellWorker things to become Manipulators ? If yuou haven't done so
> already, I'll write a simple manipulator that changes the cell's text
> - one single cell, that is - that way, every place that currently does
> that using various approaches, will be unified using one simple
> manipulator. Code reuse is our friend :)

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.

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

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

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

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]