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

List:       koffice-devel
Subject:    Re: Flake vector shapes
From:       Jaham <jaham () gmx ! net>
Date:       2006-08-28 21:25:56
Message-ID: 200608282325.56819.jaham () gmx ! net
[Download RAW message or body]

On Saturday, 26. August 2006 07:55, Thorsten Zachmann wrote:
> 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.

I think we should try to save special with their additional info. OpenOffice 
does that by using the draw:enhanced-geometry entity with an draw:type 
parameter. So it is possible, maybe we should adopt the oo way.

>
> > 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.
>
So it would not be possible to edit a star but preserve the info that it is a 
star. That is like having a text shape which you have to edit with the path 
tool, because the chars are drawn with paths.
I would like to have the possibility to edit the star as a star as long as 
possible. The star would have some special handles (see how inkscape does 
that) which the user can drag around to change the star properties of the 
shape. And if the _user_ decides to convert it to a path, the shape can than 
be edited by the path tool. 
If we have to create another tool to edit these special shapes, or if we can 
use the path tool (which then only knows about those special handles)  i 
don't know yet.

> 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.
>
You mean after enabling the create shapes tool and choosing a shape type the 
user can move the mouse over the canvas and the choosen shape is drawn at the 
cursor position? Yes that would be nice.

> Have a nice day,
>
> Thorsten

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