Issue 88939 - Initial slide position sometimes off
Summary: Initial slide position sometimes off
Status: CONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: code (show other issues)
Version: recent-trunk
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-02 10:44 UTC by thb
Modified: 2017-05-20 11:11 UTC (History)
2 users (show)

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

Attachments
proposed fix (1.98 KB, patch)
2008-05-02 10:46 UTC, thb 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description thb 2008-05-02 10:44:34 UTC 
Size the Impress window to a portrait aspect ratio. Close app, reopen and load a
document. The slide is now no longer displayed at the once-saved location, but
shifted to the right. Applied patch fixes this by always trying to keep the
center of sd::Window invariant when resizing.
Comment 1 thb 2008-05-02 10:46:47 UTC 
Created attachment 53308 [details]
proposed fix
Comment 2 groucho266 2008-05-05 10:32:13 UTC 
@thb: Can you please elaborate on how to reproduce this bug?
Comment 3 groucho266 2008-05-06 10:29:51 UTC 
@thb: What got me confused here is that this bug is not affected by the aspect
ratio of the application window, the view window, or the slide.  Moreover, it
can not be reproduced with a newly created and saved document.  In order to
reproduce you have to change the zoom factor to something that does not resize
and center the slides.

How to reproduce:
1. Create a new Impress document.
2. Change zoom factor to 75% (or some other fixed value, NOT to Entire Page).
3. Save document.
4. Close document.
5. Load document again.

=> Slide is shifted to the right.

Setting owner to CL because I am not certain that the proposed fix is the best
way to solve this.  The underlying problem seems to be that neither zoom factor
nor position is saved and restored.
Comment 4 thb 2008-05-06 10:43:30 UTC 
@af: ah, right - missed that zoom aspect, right. but this issue _is_ affected by
the window aspect ratio - if you happen to hit the initial size the view
settings are applied to (before those umpteen calls to ArrangeGui), the position
_stays_ correct.

Regarding the root cause: zoom & pos are (implicitely) stored in the
VisibleAreaXXX rectangle - the problem is that the visarea is applied to a
differently sized sd::Window, and when that one is resized, the (IMHO)
suboptimal behaviour kicks in...
Comment 5 groucho266 2008-05-06 12:17:21 UTC 
@thb: Not sure what you mean by "hit the initial size the view settings".  I can
reproduce the bug by just the steps I have described above.  No size changing
involved, apart from changing the zoom factor.  I would think that that would
qualify as hitting the initial view settings.  But then again, I have not looked
into this very thoroughly.
Comment 6 clippka 2008-06-18 12:05:11 UTC 
I'm uncomfortable changing anything in this area. We should rework all of this
and implement the long asked feature that using the scroll wheel changes the
slide...
Comment 7 Rob Weir 2013-03-11 15:00:07 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:  dev@openoffice.apache.org

Thanks!

-Rob
Comment 8 Marcus 2017-05-20 11:11:19 UTC 
Reset assigne to the default "issues@openoffice.apache.org".