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

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

[Attachment #2 (multipart/signed)]


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

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