[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:       Dirk =?iso-8859-1?Q?Sch=F6nberger?= <dirk.schoenberger () sz-online ! de>
Date:       2006-07-14 11:59:05
Message-ID: 58677.84.179.249.3.1152878345.squirrel () mail ! sz-online ! de
[Download RAW message or body]

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

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

Looks like some kind of "Flyweight" pattern, where the various shapes
share a common renderer (i.e. a QPainter object)
Is it planned to to more things, e.g. dispatching mouse and keyboard events?
This should allow for things like in-place-editing of shapes.

I think input dispatching is important because the flake doesn't know
about its contains. It may be displayed scaled to 3x its size or rotated
45degrees.
So only the container knows the correct screen-to-world transformation matrix
for its embedded flake.

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

While I more or less understand what if a Flake (or KoShape) is, I don't
quite understand about KoShapeContainer. I assume this is still not a
canvas implementation?

Regards
Dirk

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