--===============0086226407==
Content-Type: multipart/signed;
  boundary="nextPart1411384.gZ7PppEOhP";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1411384.gZ7PppEOhP
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 14 July 2006 18:31, Robert Knight wrote:
> Hi,
>
> If flake solves the zooming problems and gets around the issue of the
> whole UI changing when I double click on the embedded part then I do
> see the benefits of it.

It will indeed solve these issues for KSpread.  It does so already for=20
KWord :)

> What about copying/cutting and pasting though?  This is a very
> important aspect of inter-application interaction which doesn't work
> at all in KOffice at the moment.

We intend to have a OASIS based save/load mechanism on KoShape objects=20
which is not only meant to store them into a file but also to do=20
drag+drop and copy+paste.
I don't really have a timeline for that (as the first priority is to not=20
have regressions, and as you say, it didn't work anyway), but it=20
certainly is on the agenda.


> > - if the "parent" application allows for e.g. rotated flakes, you
> > could see a rotated table.
>
> I cannot think of a scenario where a rotated / skewed etc. table would
> be useful.

Well, its free. Nothing kspread has to do for it.  And I guess there will=20
always be users out there that find a cool use for it ;)

> A transparent table on the other hand would be useful in=20
> presentations so that the background of the slide could be seen
> through the table.

KoShape has a   QBrush background()   method that knows transparency; so=20
if the kspread region-flake will do the filling of the background like=20
that, then all is fine.  Non printable stuff can be painted in the=20
KoShape::paintDecorations method.

> > Well, the idea is, that we carry the 32k x 32k with us, but restrict
> > the visible area to an arbitrary dimension, e.g. 10x10 cells. This is
> > bad ass memory wise, but as long we don't support a Cell cluster with
> > arbitrary size, there's no other way.
>
> The size of the sheet is always referred to in the code using two
> constants KS_rowMax and KS_colMax.  Hopefully we could simply
> substitute these for a function call which would return a much smaller
> value in the case of a flake-table.
>
> As for an arbitrary sized Cell cluster, I'm sure we can fix that.

Cool ! :-)

=2D-=20
Thomas Zander

--nextPart1411384.gZ7PppEOhP
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEt8wjCojCW6H2z/QRAoNjAJ9Yr9K4jDFquCdGaD2eCZTSlgeZnACgh3GS
OlQ/0Pofqfe8EcXgBTcXkmM=
=QkwA
-----END PGP SIGNATURE-----

--nextPart1411384.gZ7PppEOhP--

--===============0086226407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0086226407==--