[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:       "Robert Knight" <robertknight () gmail ! com>
Date:       2006-07-14 16:31:08
Message-ID: 13ed09c00607140931s3f0fadd3r37fb08ff283b50ce () mail ! gmail ! com
[Download RAW message or body]

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.

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.

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

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

On 14/07/06, Thomas Zander <zander@kde.org> wrote:
> On Friday 14 July 2006 16:21, Dirk Schönberger wrote:
> > I would think something like a table which looks like it is part of the
> > container document, instead of just a widget which just happen to be on
> > the same place.
> > Think things like the following:
> >
> > - same scale factor than the parent document
> > - no scroll bars (wich belong to the KSpread document window), there
> > should be displayed just a subview of a document (say 10x10 cells),
> > instead of the whole KSpread GUI (including things like toolbars and
> > multiple sheets)
>
> Exactly; see also my introduction parag on the disadvantages of koparts in
> the long email at the start of this thread.
>
> > - if the "parent" application allows for e.g. rotated flakes, you could
> > see a rotated table.
>
> All applications allow rotated flakes as that functionality is part of the
> flake library :)
> Included skewed and scaled shapes.
>
> > From what I know, the only problem is that there currently exist no
> > good container application which could show the possible features ;)
>
> Well, there are two; the test app[1] and KWord already shows most of the
> features, but they are just not nearly as polished as I want them to
> be :)
>
> > A
> > good candidate for such a application would be something which is more
> > DTP oriented than e.g. KWord, i.e. something like Scribus, but with
> > better KOffice integration.
>
> For such purposes KWord already is very much capable of doing what you
> want. Scribus is naturally more mature, but a huge chunk of the features
> needed for DTP will be available in KWord 2.0 and various are already
> there.
> Really; I think you will be pleasantly surprised by the work already done.
> See; http://www.kdedevelopers.org/blog/91 for various blogs over the past
> weeks that show this kind of stuff I've been working on. :-)
>
>
> 1) You can get it using:
> darcs get --partial http://people.fruitsalad.org/zander/software/flake
> --
> Thomas Zander
>
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
>
>
>
_______________________________________________
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]