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

List:       koffice-devel
Subject:    Flake vector shapes
From:       Sven Langkamp <longamp () reallygood ! de>
Date:       2006-08-24 21:57:15
Message-ID: 200608242357.15597.longamp () reallygood ! de
[Download RAW message or body]

Hi,

In the last time there have been some dicussions on IRC how shapes like 
rectangle, ellipse or star should be implemented.

Here are some thoughts that crossed my mind:

The requirements for the vector shapes:
-the shapes can be created by a generic tool in all KOffice apps or special 
tools like in Karbon
-shape properties are stored (not immediate conversion to a path) and can be 
loaded and saved
-shape properties can be changed either by dialogs/palettes or special shape 
specific tools (Karbon)
-the shapes can be easily converted to a KoPathShape
-be able to add new types via plugins

The first approach to implement this was to have a KoPathShape combined with a 
KoUserData object. 

The design could be like following:
Every vector shape type (KoPathType) provides: a KoShapeTemplate for the type, 
a strategy for maniplation the shape which can either be pluged into the path 
tool or another shape manipulation tool and function to create a shape 
specific KoUserData object.

A registry contains singletons of the KoPathType's 

If a new vector shape is created, KoPathShapeFactory requests the type given 
by the template from the registry and requestes a KoUserData object for the 
given properties, creates a path and attaches the user data object to it.

Shape specific tools only work on the user data. One problem here is that the 
shape logic can only be stored in the user data object, so that the user data 
has to be able to manipulate the associated path shape.


The second approach is that the shapes inherit from KoPathShape. This is how 
it's done in KOffice 1.x. Basicly the difference is that properties and logic 
are put into the path object. I'm not sure how that would be handled by the 
shape id.

I personally prefer the second approach, but I might be completly wrong 
especially in regard to KPresenter and Kivio,

I'm open for all kinds of new ideas for this and encourage everybody to 
comment on this.


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