Bug 42994 - Editing of animation path not possible.
Summary: Editing of animation path not possible.
Status: RESOLVED DUPLICATE of bug 53993
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-16 07:51 UTC by Olaf Stetzer
Modified: 2015-11-30 12:37 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olaf Stetzer 2011-11-16 07:51:55 UTC
I have a presentation with a simple animation (move up).
I want to edit the lenght of the arrow representing the animation path.
The changed arrow is shown but when I change to another slide and come
back to the original slide, the old arrow with the default lenght is shown.
When I edit the lenght and immediately test the animation, the object is
also moved according to the old default arrow and not to the modified path.

Without the possibility to edit the path these animations are rather useless....

I hope that there is an easy bug fix to this. It seems that internally, the path which is diplayed visually is different from the path the animation is using. And that the update mechanism between these two instances is not working correctly.
Comment 1 Olaf Stetzer 2011-11-16 08:02:49 UTC
I have another useability question regarding the animation effects:

I don't know how, but at one point I managed to edit the animation path
for my object persistently. But I also eccidentially moved it a bit to the
side. The effect was that at the beginning of the animation, the object did
a short "jump" to the start of the animation path and only then followed it.

There are two useability questions concerning this:

Is this intended, that one can move the start point of the animation path
away from where the (center of the) object really is? I thought it would
probably make sens to fix the start point to where the object initially is.

If this indeed makes sense in a way I do not foresee, then it would at least
be helpful to mark the center of the object the path refers to so that it is
easy to move the starting point back to the origin of the object to avoid the
jump I mentioned above (a snap point or something like that). It is impossible
to do this precisely without help (e.g. just by eye).
Comment 2 sasha.libreoffice 2012-03-30 04:23:07 UTC
Thanks for bugreport
There exist 2 modes of editing lines: line as whole, and line as separate end points.
To switch form one mode to another, use Edit->Points or button on "Drawing" toolbar. In separate point mode editing is impossible to apply result of editing or save path. It is a bug.
Therefore, after editing of path, change mode of editing to "as whole", 9 handles will appear around path. Now we can apply path or save it.
Comment 3 Dominik Kopp 2014-07-25 07:20:14 UTC
duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=53993

workaround is to the move the entire path e.g. up and down with cursor keys. Then the modification of the points are taken over.
Comment 4 QA Administrators 2015-09-04 02:48:59 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later)
   https://www.libreoffice.org/download/

   If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
 If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results. 

4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Comment 5 Buovjaga 2015-11-30 12:37:27 UTC
Should have been closed as dupe apparently.

*** This bug has been marked as a duplicate of bug 53993 ***