From koffice-devel  Wed Jun 27 17:26:29 2007
From: jaham <jaham () gmx ! net>
Date: Wed, 27 Jun 2007 17:26:29 +0000
To: koffice-devel
Subject: Re: Flake shape transformations
Message-Id: <200706271926.29549.jaham () gmx ! net>
X-MARC-Message: https://marc.info/?l=koffice-devel&m=118296523527482

On Wednesday 27 June 2007 18:46:08 Thomas Zander wrote:
> On Tuesday 19 June 2007 21:45:15 jaham wrote:
> > If there are no objections i would like to commit that a soon as
> > possible so we have that available for our first alpha release.
>
> Today I looked at the KoShape header file and something changed since this
> mail.
> You removed the members for rotate, scale and skew.  And I am a bit sad
> about that ;)

I am sorry.

>
> I realize that we are unable to have a correct rotation in the shape if
> its skewed or similar compound alterations have been made on it.  But I
> am pretty sure that in the majority of the objects a user will see and
> create a shape will *only* be rotated. Typically even only a multitude of
> 90 degrees with lots staying at zero even.
> I am convinced of this since we are not creating a DTP(-only) suite and a
> huge number of users will not want to do many 'advanced' manipulations.
>
> So, I am sad that removing the double for rotation will now lead to a huge
> number of users having no longer access to a slider for rotation or a GUI
> or even statusbar message that shows the current rotation.
>
> => Is it possible to have 2 states for a KoShape, one where it starts with
> and has rotation / scale variables (and probably also a matrix) and
> another one where it uses the matrix exclusively?
>
> In the first mode all tools will work as normal and in the second mode a
> couple of tools that require the rotation angle will no longer be able to
> display proper information (and be disabled or something).
>
> This 'mode' would purely be internal to KoShape and ODF allows it to be
> saved, as the disabled code I wrote in KoShape::saveOdfAttributes shows.
>
> To make this more clear; consider the 'workflow'.
> 1) A new shape is inserted. It has a rotation angle of zero.
> 2) The user rotates the shape via the default tool which then sets both
> the matrix and the resulting angle back to the shape.
> 3) The user skews the object
> 4) the user rotates the object again, but is able to see the effective
> rotation as we lost that. The shape should set rotation to NaN or just
> have a bool or something like that.
>
>
> I think it would be a real gain to be able to hold on to the rotation
> until step 3.

I follow your argumentation and think there is a way to do that. You even do 
not need an extra member to hold the rotation value. As long as the shapes 
current local transformation matrix is a pure rotation matrix (besides 
translations) one can extract the actual rotation angle. If there is skewing 
or scaling mixed in, you cannot do that any more.

So let me try that and if that works at least your above mentioned workflow 
can be achieved.

Ciao Jan


_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel