Issue 95879 - AutomaticSlideAdvancement property to separate automatic slide & effect timings
Summary: AutomaticSlideAdvancement property to separate automatic slide & effect timings
Alias: None
Product: Impress
Classification: Application
Component: programming (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-11-05 16:09 UTC by chris
Modified: 2013-08-07 15:20 UTC (History)
2 users (show)

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

First version of patch (5.84 KB, patch)
2008-11-05 16:11 UTC, chris
no flags Details | Diff
Pyuno Script to test new property (3.22 KB, text/x-python)
2008-11-05 16:12 UTC, chris
no flags Details
This version removes the FIXMEs but hangs on slides with effects triggered by fixed delays (5.38 KB, patch)
2009-02-10 12:22 UTC, chris
no flags Details | Diff
Works in automatic mode, but still has a FIXME (6.84 KB, patch)
2009-02-10 12:24 UTC, chris
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description chris 2008-11-05 16:09:13 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:

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 :

Slide 1 - 30 seconds
Slide 2 - 30 seconds
Slide 3 - 5*3 seconds for effects, followed by 30 seconds equals 45 seconds total
Comment 1 chris 2008-11-05 16:11:02 UTC
Created attachment 57720 [details]
First version of patch
Comment 2 chris 2008-11-05 16:12:50 UTC
Created attachment 57721 [details]
Pyuno Script to test new property
Comment 3 chris 2008-11-05 16:23:55 UTC
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

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.
Comment 4 wolframgarten 2008-11-07 08:46:36 UTC
Comment 5 thb 2008-11-10 09:56:32 UTC
Taking over. Let's see if we can iron out the fixmes until end of November, to
get this into 3.1
Comment 6 thb 2008-11-24 14:48:31 UTC
@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 ).
Comment 7 thb 2009-01-07 14:08:09 UTC
@haggai: ping - if we want this in 3.1, please provide feedback as soon as possible.
Comment 8 thb 2009-02-09 20:09:30 UTC
Oh well. 3.x then.
Comment 9 chris 2009-02-10 12:21:34 UTC
@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.
Comment 10 chris 2009-02-10 12:22:52 UTC
Created attachment 60066 [details]
This version removes the FIXMEs but hangs on slides with effects triggered by fixed delays
Comment 11 chris 2009-02-10 12:24:17 UTC
Created attachment 60067 [details]
Works in automatic mode, but still has a FIXME
Comment 12 clippka 2011-03-14 16:25:38 UTC
cl->haggai: since this patch still causes regression we can not integrate it. are you still working on this patch?
Comment 13 thb 2012-07-13 20:47:12 UTC
Reset to default bug assignee.
Comment 14 Rob Weir 2013-03-11 15:02:37 UTC
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: