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

List:       koffice-devel
Subject:    Re: Flake vector shapes
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2006-08-26 5:55:18
Message-ID: 200608260755.19175.t.zachmann () zagge ! de
[Download RAW message or body]

Hello,

sorry for the late replay but I'm on holidays at the moment and hat no access 
to a computer for some days.

On Thursday 24 August 2006 23:57, Sven Langkamp wrote:
> 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

One problem is that we can create new shapes easily and save them as path 
shapes in odf, but saving them as special shapes in odf might be a problem as 
it would require an update of the spec. I'm not sure we need to be able to 
save it as that special type. I think that saving it as a path will be 
enough. We have to wait to see what the time will bring here.

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

This is what I had in mind when I created the path shape. I think all objects 
should be KoPathShapes in the background and I think we all think this in 
some way. We still need to know that it is a rectangular or a circle so we 
can save it as that and not as a path object. However as soon it is modified 
by the path tool (moving single points, make a curve out of a line) it has to 
be saved as a path object. My idea for this was like the following:

In the KoPathShape we have a flag m_modified which tells if the path was 
modified by the path tool and in a method e.g. save we have the following.

void KoPathShape::save()
{
	/* check if it is still in the original state and 
	 * the path of the object has not modified */
	if ( m_modified ) 
	{
		/* save it as a path object, this can save it 
                 *as a polyline or as a path object depending if 
		 * there are curves or not */
		savePath();
	}
	else
	{
		/* save it as object as it was created,
		 * this would be used for types which are defined 
		 * in oasis like rect, circle ...
		 * saveObject will be a virtual function in the KoPathShape*/
		saveObject();
	}
}

As soon the flag m_modified is set the object can no longer changed by the 
properties of the objects. Also next time it will be loaded as a path object.

I would not provide the possibility to change an object to a path object but 
do it explicit when a the object is changed by the path tool.

Also one thing I like to have is that you can see the object during its 
creation as it is when the creation is finished. So that the user can see how 
it will look form the start.

Have a nice day,

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