[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice 2.0 plan for object embedding.
From:       Thomas Zander <zander () kde ! org>
Date:       2006-07-14 16:53:55
Message-ID: 200607141853.55584.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 
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 
which is not only meant to store them into a file but also to do 
drag+drop and copy+paste.
I don't really have a timeline for that (as the first priority is to not 
have regressions, and as you say, it didn't work anyway), but it 
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 
always be users out there that find a cool use for it ;)

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

KoShape has a   QBrush background()   method that knows transparency; so 
if the kspread region-flake will do the filling of the background like 
that, then all is fine.  Non printable stuff can be painted in the 
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 ! :-)

-- 
Thomas Zander

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