KOffice 2.0 plan for object embedding.

The other day we were talking about kspread and how to let
it use flake. 
And it showed there was still quite some different opinions
about the 
topic.  We talked about it further and here is a summary of
the way we 
want to go in 2.0

First; the 1.x way is using KoPart.  An advanced KPart.
any part is implemented by providing a widget that is placed
on the canvas 
of another application.
This has various disadvantages:
- widgets can't be rotated. So parts can't either.
- no transparancy possible; its always square.
- zooming of parts sucks.  Printing a part means to zoom and
crop, which 
currently just does not work very relyably. For various
reasons.
- It tends to be too much;  having a horizontal line in
kword should not 
imply I have to embed a whole karbon doc.  Same for just 1
or 10x10 cells 
of kspread.

So; on to the flakes idea.
The idea is to have each application find parts that are to
be shared. In 
KWord this is a text shape.  Nothing more.  In Krita this is
both a layer 
and a group of layers. Maybe more.

The technical part of getting this realized means to select
what exactly 
to make into a flake.  Choose something that is usefull as a
separate 
component in other applications.
One obvious pitfall here is what it means to make something
a flake. Flake 
does not ship a canvas and a KoShape is nothing but a class
you have to 
extend and implement its paint() method for.
This has the effect that an application can reuse the
application-specific 
libraries for the painting and therefor provide a flake
without actually 
using it itself. For minimum impact on the application
internals.
To use other applications flakes you need to follow the
simple steps 
detailed in the flake docs which allows flake shapes to be
drawn on top 
of your own already existing canvas.

For simple shapes (think regularpolygon) its easy to leave
all the 
interaction to the application the user is working in. For
more complex 
shapes, or even loading a set of shapes like an eps in
karbon I suggest 
to not extend KoShape but KoShapeContainer. This gives moves
a lot of 
power to the flake itself.  This strategy really is the
replacement of 
KoPart in that it allows a whole document to be embedded
with all its 
shapes and child shapes.

There are some things you should know when you implement the
paint of your 
own KoShape inheriting class.
A KoShape uses the postscript point totally. This means you
will not need 
to do any conversion in your application.  KSpread can get
rid of the 
dozens of zooms and unzooms in Cell 
Next there is a plugin tester app, as posted on this list
earlier; load 
your plugin and see if it paints correctly and if it does
things like 
non-square borders correctly.

I suggest kspread to create a flake that will print a
pre-defined set of 
cells. (x times y)
I suggest kchart to export about the same as its part does
now.
I suggest KFormula to export about the same as its part does
now.
I suggest karbon _uses_ a shape that is in the koffice
libraries (either 
as a real shape or as an object in a separate library) for
basic vector 
shapes. It should also export a shape that is capable of
loading a vector 
graphics file of any complexity.
I suggest kivio to export a basic shape that can draw a
single stencil.  
It should also export a graph shape that combines several
stencil shapes.

These are the main apps; I have not really looked at the
others to see how 
they can be integrated.  Maybe others can follow the ideas
above and 
extrapolate.

Any questions; feel free to look me up on #koffice
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

KOffice 2.0 plan for object embedding.

Thread: KOffice 2.0 plan for object embedding.