Right now it IS in its own class -- though basically all I did was take the=
=20
relevant functions out of KSpreadTable and put them in a class named=20
KSpreadSelection and made that a member variable of KSpreadView.  Now all t=
he=20
functions that do any user initiated operation in KSpreadTable take a=20
KSpreadSelection pointer.

I'm not sure exactly how multiple selections is supposed to work but if=20
nothing else this will be a step in the right direction for that.  I was=20
focusing more on getting multiple views to work.

=2DJohn

On Saturday 08 June 2002 02:27 pm, Philipp M=FCller wrote:
> John,
>
> sorry my answer time got lost somehow. Sorry, this is KMails fault (I'm
> using cvs head).
>
> I'm fine with your change to dcop, so upload it.
> Sidenote: Is the new solution generic enough to handle when we later move
> the seleciton to an own class?
>
> In principle you are right, we shouldn't change dcop as long as we are in=
 a
> normal release cycle. But I doubt that the former KSpread was used very
> intensively, especially all the dcop funtionality and the changes to the
> dcop interface should be easy to adapt I assume.
>
> So document it (we still need a change log for such changes!) and upload
> it.
>
> Remark:
> After 1.2 release, we won't be able to change existing dcop functions for
> quite some time.
>
> Philipp
>

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel