Apache OpenOffice (AOO) Bugzilla – Issue 95879
AutomaticSlideAdvancement property to separate automatic slide & effect timings
Last modified: 2013-08-07 15:20:06 UTC
I am implementing an API driven presentation player using impress for use on a display without keyboard or mouse. I am using the AutomaticAdvancement property to advance the slides, but this advances effects and slides at the same time. For example, I have a presentation with 3 slides which should be displayed for about 30 seconds. But the third slide has 5 items which fade in when clicked with the mouse. Currently, I have these timings: AutomaticAdvancement=30 Slide 1 - 30 seconds Slide 2 - 30 seconds Slide 3 - 5*30 seconds for effects, followed by 30 seconds, ie 5 minutes total! The objective of this patch is to add a new property, AutomaticSlideAdvancement. If this property is not set, AutomaticAdvancement will be used as before. If it is set, this new timing will be used to set the delay between slides, so I can now reduce the delay between effects to, say, 3 seconds : AutomaticAdvancement=3 AutomaticSlideAdvancement=30 Slide 1 - 30 seconds Slide 2 - 30 seconds Slide 3 - 5*3 seconds for effects, followed by 30 seconds equals 45 seconds total
Created attachment 57720 [details] First version of patch
Created attachment 57721 [details] Pyuno Script to test new property
I have attached a patch which implements the proposed property, and a python script which tests the new property via the OOo API. It connects to OOo on localhost:2002 so OOo needs to be started with parameter "-accept=socket,host=localhost,port=2002;urp;" The script takes 3 arguments: <filename>.odp <slide_delay> <effects_delay> where <filename> is a file in the current working directory. The patch contains 2 FIXMEs, where I have commented out some calls. If these are not commented out, the patch does not work with slides which have a slide transition enabled, because the transition happens after the effect time (eg 3 seconds) instead of the new AutomaticSlideAdvancement time. This is because the next slide event is fired ealier than the timeout that has been set. I am postin g this version of the patch for further comments.
Reassigned.
Taking over. Let's see if we can iron out the fixmes until end of November, to get this into 3.1
@haggai: so, patch looks good, one question though - I don't really get the FIXME in sequentialtimecontainer.cxx, as that code is only triggered for *shape* effects (actually, depending on purpose, the code *does* pose a problem, in that long-running shape effects are cut short - if the AutomaticAdvancement is set to 3s, and the effect would take 5, it's interrupted. Might be a feature or not ;))? The reason for the slideshowimpl.cxx FIXME misbehaviour is the fact that makeInterruptableDelay() creates an implicit nextEvent, that gets triggered by your AutoAdvancement - just assign aNotificationEvents.mpImmediateEvent a makeDelay( boost::bind( &SlideShowImpl::notifySlideEnded, this ), slideTimeout ).
@haggai: ping - if we want this in 3.1, please provide feedback as soon as possible.
Oh well. 3.x then.
@thb: Sorry, I've not made much progress on this. I tried your suggestions, but I was still getting hangs with those changes. I was able to remove the FIXME from sequentialtimecontainer by fixing a problem in tick() that I had uncovered. The problem occurs when a slide transition takes longer than the inter-effect delay. You can reproduce this by setting the delay to be faster than the slide transition effect speed. The problem happened in the 'tick' function. This is called every N seconds, where N is the inter-effect delay. It will fire off the next event, and then reschedule itself N seconds in the future if there are more events to trigger. If there are no events pending it will not be rescheduled. That was the case during the slide transition phase, so I have modified it to reschedule in the case that it has been scheduled to fire an event, but the event has not yet been placed on the event queue. I will post the latest versions of the patch that I have. There are 2 versions. slideshow-timings3.diff incorporates your suggestions and fixes the bug above, but does not work properly. It breaks slides which have a series of transitions set to run automatically with a fixed time delay. slideshow-timings4.diff does work, but still has a FIXME.
Created attachment 60066 [details] This version removes the FIXMEs but hangs on slides with effects triggered by fixed delays
Created attachment 60067 [details] Works in automatic mode, but still has a FIXME
cl->haggai: since this patch still causes regression we can not integrate it. are you still working on this patch?
Reset to default bug assignee.
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob