Issue 48179 - Cannot step back slideshow animations
Summary: Cannot step back slideshow animations
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: code (show other issues)
Version: OOo 2.0 Beta
Hardware: All All
: P3 Trivial with 53 votes (vote)
Target Milestone: OOo 3.3
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords: oooqa
: 29790 62969 76469 98326 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-04-26 12:33 UTC by thb
Modified: 2014-04-25 13:30 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Letter to ct' editors (vol. 23/2008) (223.27 KB, image/jpeg)
2008-12-11 11:15 UTC, 123ooofree
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description thb 2005-04-26 12:33:19 UTC
In contrast to a competitor's product, the current slideshow implementation is
not able to step back in the main sequence's animations.

@dbo: please take this one over, it should be a matter of restarting the main
sequence (remotely related might be issue 45197).
Comment 1 thb 2005-04-26 12:33:46 UTC
Changed target.
Comment 2 gromer 2005-05-01 11:24:56 UTC
This is a really critical issue for everyone who wants to use Impress for more
than just a really simple slide show (one slide one content, no animations). It
really happens easily that one is to trigger handy or that a question arrises
from the audience about what was just shown etc.
I beg you *PLEASE* do not postpone this until 2.0.1!
Comment 3 Daniel Boelzle [:dbo] 2005-05-10 15:06:32 UTC
I don't see this critical, because you can step forward/back by _slide_ during
the running show. So it is possible for you to repeat the whole slide.

Comment 4 gromer 2005-05-11 11:44:35 UTC
This crucially depends on the complexity of your animation. Please
have a look at one of my example PowerPoint-Files (which unfortunately
crashes Impress 1.9.100 while Loading (WinXP))
http://www.gromer-online.de/exe/plasmaproteine.ppt
(also requires the AVI file: http://www.gromer-online.de/exe/Faust-Blut.avi)
Please note that presentations at universities are normally seen by many
students, which are potential OOo users!
Comment 5 Daniel Boelzle [:dbo] 2005-05-25 09:07:33 UTC
Set to OOoLater due to resource constraints.
Comment 6 christianjunker 2005-06-24 14:36:13 UTC
The attached file *crashed* one of the 680 builds, please check out if it still
crashes viewing this .ppt file. This would be crucial.
Comment 7 petervogt 2005-10-30 19:36:34 UTC
This is an essential feature of a presentation. For example, if you have a
10-step animation on a slide and need to show the difference between step 7 and
8 you would want to go back and forth between these two steps and not replay the
entire animation from the beginning. Please, please fix this, I believe it
should not be too difficult to implement. 
Comment 8 Daniel Boelzle [:dbo] 2005-11-25 15:22:46 UTC
@THB: as agreed to you...
Comment 9 ioul 2006-02-20 19:56:45 UTC
it's the big bug, lot of my friends at the université change with powerpoint
because this.
It is very important to compare two steps, and come back when you have click so
quick, and during  the presentation when you some questions, you look stupid
when you go one page back and after you go forward step after step.... It is not
a good commercial !
Comment 10 Regina Henschel 2006-02-27 10:52:15 UTC
*** Issue 29790 has been marked as a duplicate of this issue. ***
Comment 11 123ooofree 2006-02-27 12:39:49 UTC
since I posted issue 29790 on Jun 2 2004, I fully agree with regina, that this
current thread is identical to the previous 29790, and I'm glad to see that
finally there is some activity.
I also consider impress' inability to single-step fro **and** back within a
presentation as one of THE major draw-backs of this part of the ooo suite.
Returning to a previous animation step without having to fully reiterate the
animations of the present and the previous slides (in front of say 200 people)
is of utmost importance in any professional presentation containing a
gradual/complex fill-up of the screen with animated objects. (Leaving aside the
possibility that by error you may have simply gone one step to far and want to
get back in one step)
BTW.: Similar to some of the people here in this thread, I have also experienced
that this issue is one of the prime reasons why many many many of my university
colleagues stick with our competitors product.
My vote from 29790 has been transfered to here.
Comment 12 thb 2006-02-27 15:36:47 UTC
@all: acknowledged - also the votes. Since this involves some rework in the
slideshow core, can't promise any time frame yet.
Comment 13 gromer 2006-07-19 12:37:40 UTC
Sorry to bother again, but the new semester is coming up soon and I would like
to use my position as teacher and instructor to show people the power of Impress
and OOo as a whole.
Is there a rough timeframe when this feature will be available? I can't stress
enough that this is indeed the major remaining show stopper for me to use OOo in
my lectures and talks. I could live with the somewhat poorer antialiasing of
figures, but I rely on this feature. 
Is there anything a non programmer could do to support the development of this
feature?
Comment 14 gromer 2006-08-27 09:18:52 UTC
>It's a pity that this hasn't been fixed yet - unfortunately, I'm busy with
>other things, and this one here definitely needs a fair amount of time -
>too much for "just doing it this week".
>Thus, other tasks with lower effort and comparable impact get preference
>(which is a vicious circle, of course). There isn't really more you could
>do, short of sponsoring a programmer yourself. But OTOH, this bug is
>sufficiently annoying to me, that it will get fixed eventually.
>Thanks for your patience,

Dear Thorsten,

Any progress in stopping the "vicious circle"? How much money would approx. be
needed to get this fixed. How can I donate to get this specific bug fixed?
BTW, I think this bug deserves a P2-priority.
Thank you for all your efforts - I know you all work hard on OOo @Sun.
Regards,
 Stephan
Comment 15 thb 2006-08-29 22:30:52 UTC
@gromer: sorry, no specific plans yet  for this issue - but rest assured that 
it willl get fixed eventually.
Comment 16 utomo99 2006-10-31 10:43:12 UTC
for some people it is important to have this working. 
But maybe this issue cannot be fixed in easy way. 
I hope it can be considered maybe for OOo 2.2 

Thanks


Comment 17 gromer 2007-02-04 23:20:13 UTC
>I hope it can be considered maybe for OOo 2.2 

If I understand it correctly then 2.2 is now in Beta state. Will this issue be
fixed?
Comment 18 thb 2007-02-05 09:09:04 UTC
@gromer: unfortunately not, I'm sorry.
Comment 19 kingshome 2007-06-19 10:02:14 UTC
Having switched from powerpoint to impress, only to find I can no longer step
back and forward through the animations on a slide to demonstrate changes, I'd
like to add my voice to those pleading for a fix. It's a pretty basic teaching
technique.

2.2.1 is already out.  Any chance for 2.3?
Comment 20 thb 2007-06-19 15:51:32 UTC
unlikely.
Comment 21 wjarek 2007-08-12 01:55:02 UTC
I second all the posts above saying that this is very basic, and should be
addressed asap. I switched to Impress last year because it handles diacritics
much better than PowerPoint, and I need that feature for phonetic
transcriptions. Cool. But not being able to go back to a previous animation
without reviewing the previous slide is a real annoyance. Easily (!) the most
annoying bug in Impress. Pretty please.
Comment 22 petervogt 2007-08-12 07:54:42 UTC
Dear thb,
it is very frustrating and disappointing to see how this issue is handled. This
thread is now almost 2.5 years old, a series of users have explained in detail
why this core feature of any presentation is crucial and that the failure of it
is the reason for not being able to use Impress, people are willing to pay to
get it fixed and changing their votes to this issue. Apparently, the OO-team
still does not realize just how critical this issue is for the users and for
convincing people to switch to Impress. The priority is still P3 and it is not
even considered to be fixed in 2.3. EVERYTHING works in Impress, including step
forward in an animation and Impress is ready to replace PPT for a long time BUT
the only tiny thing that does not work is step backward. But this is essential
and until this is not fixed I and many others users will not be able to use
Impress. Because of this issue we are forced to use PPT and we can not promote
Impress! Are you aware of that? Can you please explain what exactly is the
problem in fixing it and what you need to address this issue: a gifted coder,
more time, money? Please increase the priority and get this fixed asap, so we
can use and promote Impress!  
Comment 23 thb 2007-09-11 09:36:54 UTC
@petervogt: any of the three would help (with the last one actually having the
potential to get at the first two ;-).

And now seriously: I'm well aware of the deficiencies of Impress here, rest
assured. The thing is, adding this feature is not done in two days (prolly not
even in two weeks, at least not if you want it to work reliably) - so, have not
yet been able to allocate time for this. 

Keep up lobbying/voting for this issue!
Comment 24 gromer 2007-09-11 10:24:58 UTC
>Keep up lobbying/voting for this issue!

I don't know how coding time is allocated to the different issues. But let me
tell you that this issue is extremly serious. I have shown Impress to many
people (mostly university teachers) and they all realized very quickly that this
issue exits. When I had to admit that this is indeed a missing functionality
they simply start to laugh and tell me that this software (Impress) cannot be
taken seriously.
Most people address software from a users perspective. They want a job to be
done, so they don't really care about monopols and the FOSS/non-FOSS issues.
Thus if they realize that a software doesn't provide them with the most basic
functionality, they will just drop it. 
Do NOT expect them to vote for this issue as this would require them to create
an account, to find the respective bug-report etc. Most of these people are
essentially computer illiterates - they just know those programs they need for
their daily routine.
In fact, I feel that the comparatively low number of votes for this
basic-functionality issue supports this notion.
I've convinced many MD and PhD students in our lab to use Writer and Draw, but
the use of Impress in lectures (I teach classes with up to 600 students),
department seminares etc. would have a much bigger PR-impact.
So even if it needs more than 2 weeks, please address this issue ASAP.
Let us know how we can *specifically* support progress in that direction.
Comment 25 123ooofree 2007-09-11 12:19:45 UTC
Hi, let me briefly kick in here - first with a bit of history.
Those of you able to read German :-) can check with
http://de.openoffice.org/servlets/ReadMsg?listName=users&msgNo=21260
that ever since May 2004 I have expressed my concern about this issue and I've
been going as far as demonstrating it to Ooo representatives 'on-the-spot' at
the CeBIT show. 

Personally I consider this issue to be THE most serious issue in Ooo Impress and
I agree, that it is very frustrating to see how it is handeled.

However, over the years, I've also come to realize why this is so: the vast
majority of people I've seen using Ooo Impress or other presentation software
have only little animations - maybe one or two at most - on their viewgraphs,
i.e. they use Impress like a PDF full screen viewer. This also pertains to many
of the PR presentations I've seen from Ooo-team people. In that case there is no
urgent need for resolution of this issue - in some sense their is no need for
Impress in those cases at all. The real need for complex animation built-up on
viewgraphs, and therefore also the need to go back-and-fro is mostly with
scientists, university people, and maybe teachers. (While I usually don't like
to do this, let me mention that I have 'some' experience here: I'm a professor
of physics at a major German technical university.)

It seems to me, that the Ooo-team just does not realize (or care about?) the
additional 'market-share' that it could gain with users from the teaching and
research part-of-life ... if this issue would be fixed. So, I'm pessimistic.

In any case, while I've come to adjust myself to this annoyance in Ooo Impress,
I do not recommend using it to my students - simply because of this issue. And
99% of my colleagues whom I've ask about it feel the same.

Very best,
Wolfram (alias 123ooofree)

Btw.: my current and 2nd to most critical issue with Impress is 68812 ... also
no resolution ... and many many presentation screwed up because of it.
Comment 26 ftack 2008-03-16 17:33:23 UTC
This issue is not a defect, but an enhancement request, albeit a much needed one.
Comment 27 kpalagin 2008-03-16 20:30:02 UTC
*** Issue 76469 has been marked as a duplicate of this issue. ***
Comment 28 longborderd 2008-04-04 01:18:23 UTC
This is a VERY important feature for Presentation software.  Impress is more
than a SLIDE SHOW program.  But with out being able to go back one step, it
really can't be used as anything but a SLIDE SHOW.  Please, please, please help
us out.  OOo, Impress specifically, would be much more widely used in the
teaching/education world if this was a reality!  It really would!!!!!

If some coder out there wants to tackel this I'm sure a bunch of us would send
you some moola through paypal or something!!!!  PLEASE!!!!!
Comment 29 gromer 2008-04-04 21:02:22 UTC
Since I opened this issue in 2005 I haven't seen any progress from the users
perspective. As most recently "longborderd" and before many others have
mentioned this is one of the most important if not the most important reason why
Impress (and also to some extend Linux and other non M$-systems) is hardly used
in professional settings.
As "longborderd" said, I also firmly believe that many (including myself) would
be willing to donate if there was a competent code willing to fix this.
Is there at least reasonable hope to assume that this issue will be solved in
OOo 3.0????
Comment 30 thb 2008-04-06 05:48:19 UTC
@gromer: the target is "OOo later", which implies that, no, it's unlikely that
something is changing for 3.0. I'm sorry.
Comment 31 leggewie 2008-04-06 11:11:52 UTC
@thb: And you know that to call that a shame is a gross understatement.  

Is there *anybody* at all working on Impress?  It does not look like that to me.
 In that case, I frankly suggest to remove Impress from OOo.  If there is (thb,
are you?), then I suggest that this person seriously looks at their priorities
for this module.  As others have said, there is not much that is more important
than this bug, yet after several years, we are being told that there is not even
a schedule on when to put this in place.  I am at a loss for words.
Comment 32 erasmus_europe 2008-05-27 19:10:53 UTC
Disappointing. That's all I have to say. I have three days for one of my Phd
checkpoints, so I will export my presentation to Microsoft PowerPoint and use
that . I cannot risk having to replay all animations on the slightest mistake.
M$ wins again. Goodbye, OpenOffice Impress...
Comment 33 irieger 2008-06-24 09:12:43 UTC
I also would like to express the urgent need for this 'step back' functionality
in Impress. Considering the timeframe of this issue (more than 3 years by now!)
we should see more progress. I do work a lot with Impress and have been missing
this functionality since years. Please do not underestimate this issue. It is a
major showstopper for a lot of users (especially those trying to switch from
PowerPoint).
Comment 34 gromer 2008-06-27 23:47:53 UTC
Is there anyone really trying to fix this issue? If so, how can I help and what
is a realistic time frame?
I admit that this issue (and an additional one 27377) finally gave me reason to
ask SoftMaker for the release date of their Office 2008 for Linux.
I wonder why fancy new transitions effects etc. are build in and still worked on
while urgently needed basic functionality is still missing.
Comment 35 elfunesto 2008-09-19 16:46:48 UTC
I just tried oOo rc1 and was really disappointed to see that this problem is
still not solved. Unfortunately, this bug is the only reason why I cannot use
Impress. I really hope that a solution will be found in a next release.
Comment 36 gromer 2008-12-07 16:20:51 UTC
Okay, this *STILL* not fixed in 3.0. Will anyone care about this in 3.1?
As far as I understood the reason not to deal with this in 2.4 was the fact that
the things under the GUI hood would need a lot of changes to allow for this
functionality. 
So if these changes were not incorporated in 3.0 when will they?

I have already bought Softmaker Presentation due to this issue. If there will be
no clear time frame when this will be fixed I will start to convert all my
presentations to it and from my personal experiences OpenDocument-Format is only
partially interchangeable in presentations due to different features. So this
might make me leave OOo Impress forever.
Anything I can do (other than code) to support getting rid of this most anoying
issue?
Comment 37 eric.bachard 2008-12-08 12:37:57 UTC
+me on CC

Can someone add the request on the Education Project Effort wiki page ? Thus we maybe can start 
working on that with students (no guarantee at all)

URL :  http://wiki.services.openoffice.org/wiki/Education_Project/Effort

Thanks in advance !
Comment 38 leggewie 2008-12-10 15:40:44 UTC
The page requires yet another login.  ericb, maybe you can add the following
lines or something similar to that page?

   allow Impress to go back in an animation sequence

    * goal: Impress should allow to go back in an animation sequence
    * Problem : Impress can go back one slide at a time.  It is currently 
      impossible to go back one step in an animation.  It is necessary to
      repeat the complete slide with all animations.  This is unacceptable
      for a professional presentation program.  Issuezilla 48179 has more
      information.
    * Time plan : TBD
Comment 39 123ooofree 2008-12-11 11:13:42 UTC
So, it seems there is some promissing new activity on this very annoying issue.
I'll keep my fingers crossed.

Along this line and just for the record and maybe also to put some additional
motivation into this effort: in my part of the world issue #48179 has recently
had its rather embarrassing 'comming out' into public.

Here we have a *very* widely distributed computer magazine, the "ct'" (computer
technique). A recent issue of it (22/2008) was devoted in part to what they
called the 'office show-down' comparing M$ and OpenOffice. Therein, amongst
others, they concluded that both presentation modules, i.e. M$-PPT and Impress
would do their jobs equally well ... sounded good for Impress ... but not for long.

Immediately following that article a rather sarcastic letter to the editor (not
from me :-) ) was published (vol. 23/2008) headed 'No way back with Impress'.
I'll create a corresponding attachment to this issue. For those unable to read
German, let me just summarize, that this letter, in detail, describes exactly
issue #48179, stating, eg., that '... with Open-Office-Impress you cannot
perform one of the *most* *elementary* *operations* of a presentation, i.e.
stepping back in animations ...' Finally it concludes with '... starting at 5 to
10 animation steps and an audience of 100 you will at least have the laughs on
your side ...'. Sounded very bad for Impress. 

Interestingly there was no reaction from the OpenOffice-community on that letter.
Even though the "ct'" is really *the* German PC-magazine.
Sounds even worse for Impress.

So PLEASE PLEASE PLEASE fix this issue.

Regards,
123ooofree
Comment 40 123ooofree 2008-12-11 11:15:51 UTC
Created attachment 58710 [details]
Letter to ct' editors (vol. 23/2008)
Comment 41 eric.bachard 2008-12-11 12:03:18 UTC
@leggewie 

I added goal / problem on the wiki page. FYI, I'm contacting (today) several professors for applications 
starting next semester in their reepsective schools. I hope a group of students will work on that.


Comment 42 groucho266 2009-03-04 08:56:14 UTC
I am taking this one over.

I have analyzed the problem and found a solution that is not too hard to implement.

The straightforward way to handle the rewinding of single effects seems to be
to, well, rewind the last effect (sequence) that was triggered by user input. 
This turns out, as mentioned above, to be quite hard to implement with the
current architecture of the slide show.

A simpler but not quite so elegant way is to rewind the current slide and play
back all main-sequence effects except the last one.  There are two drawbacks to
this approach:

1. When a main sequence effect is undone then all effects that do not belong to
the main sequence are undone as well.  This includes for example effects
triggered by clicking on some shape.  This behavior is unfortunate but I see no
way around it.

2. Redisplaying the current slide and then replaying the effects is probably
somewhat slower than just undoing the last effect.
Comment 43 eric.bachard 2009-03-04 09:18:47 UTC
@af :

FYI, the subject has been proposed to students from Seneca College ( see http://wiki.services.openoffice.org/wiki/Education_Project/Effort/Improve_Impress ) 

If ever (I have no idea whether a student will apply) one student applies for this task, are you interested to 
work together ?

Thanks in advance :)
Comment 44 groucho266 2009-03-04 09:36:31 UTC
@ericb: Well, I have already implemented the outlined solution and am currently
in the process of polishing my changes and checking them in.  But I am sure that
my fix can still be improved.  So, any help is welcome.
Comment 45 groucho266 2009-03-04 09:50:32 UTC
I will be checking in my fix in multiple stages so that I can explain the
different aspects a little bit.

I am starting with the modified interfaces in offapi.  Please note, that both
affected interfaces are not published and therefore may be changed.

Added previousSlide() to com.sun.star.presentation.XSlideShow.  Obvious change,
I think.

Added two properties to XSlideShow::displaySlide.  The properties allow a slide
to be displayed without transition effect and can trigger the execution of all
main sequence effects.  Both are used when going back one effect leads to the
previous slide.  In that case the previous slide should be displayed as fast as
possible (no transition animation) with all effects already executed (so that
the user can continue travelling backwards through the effects.)  See IDL file
for details.

Added flag to XSlideShowListener::slideEnded() so that the listener
implementation can detect the traveling order that caused the slide to end. 
With this the listener (especially the SlideshowImpl in sd) can decide whether
to change to the next or the previous slide.

Revision of this change is 268793.
Comment 46 groucho266 2009-03-04 10:09:03 UTC
Changes in sd:
The changes in sd are straight forward.

-  Added/changed key definitions for going back one effect.  This mirrors now
the key definitions for going forward one effect.

- Added the logic for going to the previous slide when there is no effect to
undo on the current slide.

Revision of this change is 268796.
Comment 47 eric.bachard 2009-03-04 10:13:23 UTC
@af :

I have forwarded the information to the students. Let's wait if the subject will be choosen :)

Thank you very much !  
Comment 48 groucho266 2009-03-04 12:09:10 UTC
Fixed a bug in slideshow::internal::LayerManager where an internal data
structure was not kept up-to-date.  A mapping between shape and layer got out of
sync when deactivate() was called.  This was triggered when rewinding effects
while their animation was played and resulted in shapes not displayed anymore.

Revision of this change is 268817.
Comment 49 groucho266 2009-03-04 13:56:13 UTC
Checked in the final part of the fix, in slideshow.

As outlined above the new class EffectRewinder replays the main sequence effects
up to but
not including the current effect.  When no effect of the current slide has yet
been played
then it switches to the previous slide and plays all of its main sequence effects.

In order to avoid waisting time and to reduce visual artifacts the slide
transition of the
current or the previous slide as well as the animations of the replayed effects
are not
shown.  For the same reason unnecessary screen updates are suppressed.

In the following you will find a per-file list of changes (all in the slideshow
project):

source\engine\effectrewinder.cxx
source\engine\effectrewinder.hxx
source\engine\makefile.mk
    This new class is the center of the effect rewinding.


source\inc\usereventqueue.hxx
source\engine\usereventqueue.cxx
    Fixed triggering of nextEffect.  The nextEffect event was not properly
executed before.
    Triggering of nextEffect after skipping current effect is now optional.

source\inc\eventqueue.hxx
source\engine\eventqueue.cxx
    Added another way to schedule asynchronous events: addEventWhenQueueIsEmpty().
    isEmpty() and nextTimeout() now take into account all event queues.

source\engine\animationnodes\basenode.hxx
    Made isMainSequenceRootNode public

source\engine\animationnodes\sequentialtimecontainer.cxx
    Fixed triggering nextEffect after skipping the current effect.

source\engine\screenupdater.cxx
source\inc\screenupdater.hxx
    Screen udpates can be locked in order to prevent intermediate repaints.

source\engine\slideshowimpl.cxx
    Trigger the EffectRewinder on some user events.  Provide functors to the
EffectRewinder
    for redisplaying the current slide and for switching to the previous slide
so that
    SlideShowImpl does not have to expose its internals.


Revision of this change is 268834.
Comment 50 thb 2009-03-04 16:24:30 UTC
@af: thanks a lot, good stuff & I like the workaround!
Comment 51 gromer 2009-03-04 19:27:59 UTC
First of all I would like to express my thanks to af for trying to provide a
workaround for this issue.
I do, however, hope that it will also be regarded as such - a WORKAROUND.
It is not a proper solution to the problem. I haven't tested it  so far, yet, I
fear that if a lot of animations precede the one to be rewinded that performance
will be a serious issue.
Thus I sincerely hope that the OOo gfx-folks continue to work on a real solution.
Looking at the official status of the issue as "resolved" and resolution "fixed"
makes me, however, doubt that this is the case.
Could you kindly clarify?

Again, many thanks to af for bringing this issue somewhat forward, and I hope
you don't take my comment as an offense in any way.
Comment 52 groucho266 2009-03-05 08:20:29 UTC
Maybe I was a bit misleading in one of my earlier comments.  I would not call
this a workaround.   Also, the mentioned possible performance hit will likely
not be a real issue.

Without huge changes to the architecture of the slide show, which could come
close to a rewrite of its core, you will not be able to solve this problem much
better.

So, please, before anybody calls for a different solution or spells workaround
in uppercase letters, give the current solution (when it is build and properly
tested and integrated) at least a try.
Comment 53 clippka 2009-03-05 11:45:06 UTC
Dr. André is a very modest man and a perfectionist. I would not call his
implementation a workaround in any way. In theory there are more efficient ways
to go backwards inside a smil animation hierarchie, but the overall win would
not justify the cost and complexity of such solutions.

If André talks about playing the effects foreward, it is not the same as doing
the animations on screen. He can do it with a lot less steps and without
painting it. Processing only the internal effect logic is something your trusty
8-Bit Commodore 64 would be bored by rather sooner than later. The only
'performance penalty' is that the screen has to be drawn completly once. Yes
this may take a big fraction of a second, but as a one time result of a user
input this is more than acceptable.

So everyone please encourage André for his very fine work solving a problem
where others tried and have faild!
Comment 54 oyvindnordstrand 2009-03-05 12:18:02 UTC
So for me (and us?) it-guys with no (or "just a little") knowledge in
programming and stuff: What do I now do, to get this workaround (or whatever we
call it) implemented into our software, so the "on-step-backwards"-functionality
can be a part of the slideshow-part of our impress-installations?

Or is it somebody else who shall implement it and I have to waite for an upgrade
of ooo?

Thanks!

-Øyvind
Comment 55 groucho266 2009-03-05 12:23:02 UTC
This is a regular bug fix (well, more of an enhancement).  Just be patient and
wait until it gets integrated.  Then either grab the resulting developer version
or be even more patient and wait for OOo 3.2 to arrive.
Comment 56 gromer 2009-03-05 19:57:18 UTC
Okay, af's & cl's comments were clarifiyng and sound promising. As I already
tried to point out in my previous post:
I DO appreciate Dr. André's activity VERY much and if there is any way to
support him, please do not hesitate to post it here! By no means did I intend to
discourage him - to the contrary! If it was understood this way, please take my
apology.
thb called the solution a "workaround" in his posting and af's own description
of his solution pointed in the same direction - and my experience with other
workarounds in OOo is far from satisfying.

If a redraw of each effect can be  completely avoided it sounds reasonable to
assume that it can be done within an acceptable time frame and I hope this
assumption will turn out true - I'll keep my fingers crossed for it, promised!

I assume that - if performance will indeed not become an issue - Dr. André's
work will help >95% of the users (and I hope that for most of the time I will be
amongst those)
Yet - as he and others have pointed out - further improvement will only be
possible by modifications of the Impress-core. As further functionalities will
be added to Impress in the future, I assume that not dealing with this approach
will make it even more problematic in the future as most of the addition to
Impress will be more less dependent on its core, so even more code will have to
be redone and adapted. 

But again, I AM VERY enthusiastic to see REAL progress on this issue, and I
truely like to thank Dr. André and anybody who did, does or will assist or
support him.

Did I get that right, that once 3.1 is out any later dev-version will have the
new function build in for testing?


Comment 57 leggewie 2009-03-05 21:30:36 UTC
Great, many thanks!

Will the patches likely apply cleanly to 3.0.1?  In that case, I think there's
still time to try and get this into Ubuntu Jaunty.  I can probably put in some
effort to that end, but I'd like to check here first.
Comment 58 groucho266 2009-03-06 06:58:31 UTC
Regarding the release/availability of this fix: it is targeted at OOo 3.2 and
thus independent of the release date of OOo 3.1.  It will be in one of the
future developer versions that lead up to OOo 3.2.  The exact date depends on
how long fixing any remaining bugs and testing will take.

Regarding the integration into OOo 3.0.1:  I have a bad feeling about this. 
While it will probably not cause many technical problems, it might introduce yet
undiscovered regression bugs.  I already found one situation where rewinding
does not yet work as advertised (I am currently working on that, details will
follow later).  So, please be patient.
Comment 59 thb 2009-03-06 10:25:34 UTC
@leggewie: just backported the fix to 3.1, works there; 3.0.1 should be (almost)
the same. I'm willing to take the risk of some minor regressions.

(disclaimer: this refers to leggewie's question and therefore to ooo-build).
Comment 60 groucho266 2009-03-06 12:36:06 UTC
@thb: Good to hear that the fix works with OOo 3.1.  Thanks for testing the fix.

@leggewie: I am more concerned with the quality of the fix than with its early
integration.  If you are willing to introduce regression bugs into an already
delivered version then go ahead.  Just make sure to grab all bug fixes (see
below for a description for some recent changes).

@thb, leggewie: Is it OK if I forward any 3.1 and 3.0.1 specific regression bugs
to you?


Thb was so kind to fix two minor build breakers.  He also made some cosmetic
changes to methods names in the new EffectRewinder class: the slideshow module
seems to be one of a few (the only one?) modules that has its own rules of code
style. The revisions of these changes are 268979 and 268980.
Comment 61 thb 2009-03-06 13:16:32 UTC
@af: ubuntu issues should go to launchpad, debian to bugs.debian.org etc., and
I'll generally close them as 'invalid' here - so yeah, send all those
complainers my (or leggewie's) way! ;)
Comment 62 groucho266 2009-03-09 11:50:08 UTC
Fixed the handling main sequence effects that start automatically with a new slide.

Revision is 269072.
Comment 63 groucho266 2009-03-25 14:32:35 UTC
Added support for stepping back by effect to the Presenter Console extension.

Note that previous changes for this issue included incompatible changes to
(unpublished) UNO API interfaces.  Therefore the Presenter Console extension
currently available in the extension repository (versions up to and including
1.0.2) can not be used anymore together with these changes.

Revision is 270026.
Comment 64 groucho266 2009-04-27 12:46:15 UTC
To improve debugging of event handling I have added descriptive strings to
events on their creation.

SVN revision is 271265.
Comment 65 groucho266 2009-09-14 16:26:33 UTC
Changing target to OOo 3.3
Comment 66 groucho266 2009-09-14 16:27:47 UTC
Reopening issue because of problems with shapes that have more than one effect
assigned to them.
Comment 67 groucho266 2009-10-14 13:58:23 UTC
The problem was not related to multiple effects but with animations that have an
active auto_reverse part, like "Put on the Breaks".  This effect has two
explicit parts and a third implict part.  Part 1 is the translation from left to
right.  Part 2 is skewing to a 45 (if I remember correctly) degree angle. Part 3
is part 2 with auto_reverse applied: skewing back to an upright position.

Now try this,  when the animation is half way through, press the Down key. 
This, supposedly, skips over the rest of the animation and displays the end
result.  What really happened was that the shape was displayed in the state
directly after part 2 had finished: skewed to the right.

The same happened when going back a following shape animation.  The end result
of its previous effect (the "Put on the Breaks" animation) was displayed skewed
to the right.

Fixed that in FromToByActivity::performEnd() by taking the auto_reverse flag
into account and, when active, using maStartValue instead of maEndValue for the
final frame of the animation. 

SVN revision of the change is 276897.
Comment 68 kortandsa 2009-10-20 09:51:26 UTC
I don't see how this issue is resolved.

Still got the problem of not being able to go one step back in animations.

Got the problem with any simple animation(e.g. "erscheinen" which should be
something similar to "appear" in english).
Comment 69 groucho266 2009-10-23 14:33:26 UTC
@wg: Please verify.
Comment 70 wolframgarten 2009-10-27 11:40:09 UTC
Verified in CWS.
Comment 71 mihkel 2010-10-25 06:56:18 UTC
Why is the Resolution : FIXED?

I use version 3.2.1 build 9502 and I Have simple "picture appear on click" kind 
of animations, and I still cant step back one animation at a time.

I still have to go back to the beginning of slide. Even worse, if I press 
leftarrow on a slide were I only want to go back on animation, it takes me back 
to previous slide. If the previous slide has also animations, I have to cycle 
through all these animations and then the beginning of the original slide to get 
were I was going.

It looks rather unprofessional if I do this several times in front of an 
audience. 
Comment 72 icyfeet 2010-10-25 07:16:59 UTC
It works in oo 3.3beta so I think it will in 3.3 and it already works in go-oo
(http://go-oo.org/) which is shipped with most linux distributions.
Comment 73 wolframgarten 2010-10-25 08:13:38 UTC
Closed.
Comment 74 Edwin Sharp 2014-04-21 16:39:45 UTC
*** Issue 62969 has been marked as a duplicate of this issue. ***
Comment 75 Edwin Sharp 2014-04-25 13:30:50 UTC
*** Issue 98326 has been marked as a duplicate of this issue. ***