Thank you for reporting this enhancement request! I can confirm that this is a valid enhancement request on:
Version 4.1.0.0.alpha0+ (Build ID: 9a46e5614f5a0e0bdce3c497f81ca529da8fb5c)
Date:   Mon Mar 18 18:59:09 2013 +0100 
Platform: Bodhi Linux 2.2 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm the enhancement request I am marking as:

New (confirmed)
Enhancement
High - would be very very useful for anyone editing large presentations or someone giving a presentation over multiple days and don't want to memorize where they left off. 

Keywords - 

Whiteboard Status - ProposedEasyHack

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material

Can please anyone tell , which part of code to poke at .

So - for Writer, this is saved inside the settings.xml file, a bit indirectly via

      <config:config-item config:name="VisibleAreaTop" config:type="int">-275</config:config-item>
      <config:config-item config:name="VisibleAreaLeft" config:type="int">-3919</config:config-item>
      <config:config-item config:name="VisibleAreaWidth" config:type="int">33347</config:config-item>
      <config:config-item config:name="VisibleAreaHeight" config:type="int">19669</config:config-item>

. For Impress, one would have to extend SdXMLExport::GetConfigurationSettings() from xmloff/source/draw/sdxmlexp.cxx for the export, and possibly XMLConfigItemContext::ManipulateConfigItem() from xmloff/source/core/DocumentSettingsContext.cxx for the import - and of course Impress would need to get some suitable document settings property, e.g. "CurrentPage" or somesuch, that then needs handling in sd/source/ui/unoidl/UnoDocumentSettings.cxx

Thorsten i think the current slideshow.cxx does mention something like the current page number.I dont know if this is correct but i think we can surely use the same thing by XML export (as you have mentioned in Comment#3) .

Any further explanation or suggestions would be welcomed and appreciated.

(In reply to comment #4)
> Any further explanation or suggestions would be welcomed and appreciated.
>
Did you try to add a CurrentPage attribute to Impress API already? That should be relatively obvious from the referenced code.

Hey Thorsten! I have just started to read some code according to the Comment#3 by you and looking at the code pointers and hence would like to go ahead and finish this job and work more and more now . I just wanted to know what do you mean by the term "export" in Comment#3 ??

adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details

Removing comma from whiteboard (please use a space to delimit values in this field)
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started

i am currently working on this bug, i ll keep the status updated..

(In reply to comment #9)
> i am currently working on this bug, i ll keep the status updated..

Just like to say thanks to all who are contributing to this request. With presentations with over a hundred slides, this fix will be a great saver.

I am sorry that i haven't been updating my status. I had stopped working for a while, but now i have taken it again.. 
i have a question, 
I noticed a function - sd::FrameView::ReadUserDataSequence, in which there is a function call to sd::FrameView::SetSelectedPageOnLoad()? http://docs.libreoffice.org/sd/html/classsd_1_1FrameView.html#aa52d470e1ee409a897dec8d4d7918d9f, here it says that the function stores the page that was selected while last saving this document.
But this property is not being used.(if i am right)
 I ve researched pretty much about the bug, found many pointers, but i didn't find the pointer for saving a property.. I ve tried to find it using the above mentioned properties such as VisibleArea etc.. but haven't had enough luck on that. I think WriteUserDataSequence and ReadUserDataSequence are the places where the read and write is happening, but am not sure whether i am right on that part.. Can somebody please guide me? 
thank you.

You should go to the IRC channel or the dev mailing list - not many people will follow the bug tracker so you might get faster/better feedback going to the list/chat

(In reply to comment #12)
> You should go to the IRC channel or the dev mailing list - not many people
> will follow the bug tracker so you might get faster/better feedback going to
> the list/chat

I usually ask in the irc or dev list. i wanted to update what i ve done, and thought i will put a question in there too. I ll ask in IRC.. Thank you for the quick reply :)

I have submitted the patch for review, hopefully it gets accepted. :)
https://gerrit.libreoffice.org/#/c/8946/

(In reply to Sujay from comment #14)
> I have submitted the patch for review, hopefully it gets accepted. :)
> https://gerrit.libreoffice.org/#/c/8946/
Sorry..just a ping. Has it been implemented? Seems the issue still exist on 4.3.2.2 and 4.2.6.3

(In reply to ign_christian from comment #15)
> (In reply to Sujay from comment #14)
> > I have submitted the patch for review, hopefully it gets accepted. :)
> > https://gerrit.libreoffice.org/#/c/8946/
> Sorry..just a ping. Has it been implemented? Seems the issue still exist on
> 4.3.2.2 and 4.2.6.3

Sorry I took so much time to reply.
The patch submitted is not accepted yet. Have to make some changes. I had stopped working on this, I will try my best to complete this as soon as possible.

(In reply to Kumāra from comment #0)
> I'm working on a presentation and lots of slides. Every time I reopen the
> file, I have to scroll like crazy to the position I last left it. Can we
> implement a similar feature available in Writer, that is to have LibO save
> the last slide in view when saving the file?
> 
Arghh. So actually the very nice detective work Bubli did in
https://gerrit.libreoffice.org/#/c/14782/ shines a different light on
this issue.

In fact, the functionality requested *is already there* - it is
currently triggered by alt-shift-F5 after loading a file that was
edited by LibreOffice.

Background: the old behaviour got changed in the course of some user
experience-informed cleanup work in 2005, spec & feature request here:
https://bz.apache.org/ooo/show_bug.cgi?id=50902

This was previously mapped to shift-f5 (similar to Writer, and Word),
and got remapped alongside the fix for tdf#58505.

I have no overly strong opinion on the issue, except that _probably_
an Impress document is opened more often by people who are not
interested in the last editing position.

CC ux-advise for additional thoughts.

(In reply to Thorsten Behrens from comment #17)
> In fact, the functionality requested *is already there* - it is
> currently triggered by alt-shift-F5 after loading a file that was
> edited by LibreOffice.

Really? Thanks. That would be good enough for me, but it doesn't work on my LO4.1.6.2. (Not upgrading till some regressions (major for me) are fixed.)

I don't see the purpose of having LO open it at the first slide. If it's so that one can start the slide show there, F5 does that just fine regardless where the user is looking at, or where the highlight or cursor is.

In any case, if there's a shortcut to get to where I left off, I'd be contented with it, but now it's not working for me.

Can anyone else confirm that alt-shift-F5 does as said above?

(In reply to Kumāra from comment #18)
> (In reply to Thorsten Behrens from comment #17)
> > In fact, the functionality requested *is already there* - it is
> > currently triggered by alt-shift-F5 after loading a file that was
> > edited by LibreOffice.
> 
> Really? Thanks. That would be good enough for me, but it doesn't work on my
> LO4.1.6.2. (Not upgrading till some regressions (major for me) are fixed.)
> 
> I don't see the purpose of having LO open it at the first slide. If it's so
> that one can start the slide show there, F5 does that just fine regardless
> where the user is looking at, or where the highlight or cursor is.
> 
> In any case, if there's a shortcut to get to where I left off, I'd be
> contented with it, but now it's not working for me.
> 
> Can anyone else confirm that alt-shift-F5 does as said above?

alt-shift-F5 works fine and takes to the last edited slide.
Ubuntu 14.04 , LO Version: 4.2.7.2

> Can anyone else confirm that alt-shift-F5 does as said above?

It works for me as well, LibO 4.3.1.something, Debian testing. I'm not so sure in which timeframe bug58505 got fixed (ergo, the shortcut got re-mapped), but you might want to try if Shift-F5 works for you then ... 

UX team: any creative ideas how to make jump to the last edited slide functionality more visible? Few users know about the kbd shortcut, so maybe some context menu? Toolbar button?

(In reply to Katarina Behrens from comment #20)
> > Can anyone else confirm that alt-shift-F5 does as said above?
> 
> It works for me as well, LibO 4.3.1.something, Debian testing. I'm not so
> sure in which timeframe bug58505 got fixed (ergo, the shortcut got
> re-mapped), but you might want to try if Shift-F5 works for you then ... 

I've tried that. It's for starting the slide show from current slide.

So, no joy for me till I upgrade pass LO4.2, which then means I've to deal with regressions I'm facing.

Anyway, thanks...

I wonder how alt-shift-F5 got mapped. Can't find a reference to it anywhere else in Bugzilla, or Help.

But, yes, please do make it known, at least in https://help.libreoffice.org/Impress/Shortcut_Keys_for_Impress

As a bit of a noobie here, (though I worked on gnu c) And as a self-appointed voice for the Mac Users of the World, there is a user paradigm shift afoot that should be considered.

In the truly Apple World, it is abhorrent to take away the effort of a user.  The user should not need to tell the word processor or other tool that he wants to keep what he has done. The user should not be forced to give up his 'place' just because his machine shut down.

There is a huge appreciation for context and thought saving. I hate to have a popup come into my world as I work - and I hate to have to remember where the heck I was when I had to divert my attention. (I am both an attorney and a developer, so I must say that it gets very difficult to keep my head anywhere).

So, step back and consider that the users who had previously expressed their opinion regarding this 'feature' may not understand how nice it really is to be taken care of instead of taken advantage of. This is the whole story of new development toward ease of use. Let them keep their progress and their mind. They, like I, are suffering more and more from loss of memory even though pot is becoming legal.

It should not be so hard that Kumara or others have to ask for the protection. It should also include what Apple apps do - get that user right back to where he was - ALWAYS (unless you are using MS OFFICE)

D

(In reply to Dennis Van Dusen from comment #22)
> It should not be so hard that Kumara or others have to ask for the
> protection. It should also include what Apple apps do - get that user right
> back to where he was - ALWAYS (unless you are using MS OFFICE)
> 
This is beside the point in this context. Storing the last edit pos in
the document, and then having each and every user who's just consuming
the content start at random pages/slides, is the trade-off at hand.

Your otherwise valid suggestion is a different beast, please file a
separate bug for it (i.e. storing last-edit positions for a number of
documents in the _application_ config). Or maybe that bug is already
there.

OK, you made me think more.  

Please allow a further thought.

How many people know how to get to the top of a document in their tool of choice with one key combination?

OK, for an alternative position, 

How many people know how to get to the place in their document where they were last working with one key combination?

And, worse: 

What is the standard for that key combination on their tool of choice and platform?


These things make a big difference when you are working at the varsity level as Libre is now doing. 

I cannot really see where the differential is between the issue being addressed and what I would hope the answer is.

I do understand that there are writers and consumers. In fact, there is value for both of them, unless they are using the same state / cache.  

If a user is first viewing a doc, then great - start them at the beginning - storing that point for them where it should be stored - often in their own machine's cache, but there is no reason not to allow that to be stored in their 'local' copy of the doc. The only major limitation for storing it in a communal copy is the possible number of editors.

The above stands true for all users, actually - especially in context of collaborative work.  Each user needs their own edit point. Each deserves to have it preserved - unless that point in the presentation has been destroyed. 

In the 'short term' use case, if a flash user had no way of stopping and then restarting their copy of a presentation, not many would be happy. For collaborators, a longer period is involved, but the same behavior is needed - both for their short and long term use cases.

For all users, -- I should qualify -- for all Mac / Ipad / Iphone .... users, it is consistent to preserve the exact view for each user anyway.  The above is consistent with that standard. It really is helpful - for all users, collaborative as well.

So, I take the point, but I think the issue will resolve in only one outcome - everyone gets their own 'last edit' pointer, but that pointers storage area might not be in the document for everyone.

D

(In reply to Dennis Van Dusen from comment #24)
> So, I take the point, but I think the issue will resolve in only one outcome
> - everyone gets their own 'last edit' pointer, but that pointers storage
> area might not be in the document for everyone.

What you're saying here is already true for Writer and Calc. I didn't understand why the same wasn't true for Impress until Thorsten mentioned it. (Comment 17)

Why was that implemented? I can only guess that people wanted to be able to start the slide show right away—from the 1st slide of course. (Can't think of any other reason.) But that ability to do this is easily achieve by pressing F5.

So, whatever it was the reason for the change, I don't see any reason to maintain it.

I don't want to upset others who like it the current way though. (Too lazy to use F5?) So, perhaps providing an option is safer.

Apparently, such an option was there in OOo 2.0. Got this from a file at https://bz.apache.org/ooo/show_bug.cgi?id=50902:

5.2.1 Option: Restore Editing View
The Options dialog – section OpenOffice.org, panel View – contains the option “Restore: Editing view”.
If this option is marked all parameters when the document was last saved will be restored on reopening the document. In text documents, this includes the cursor position; in spreadsheets the active sheet; and in presentations the selected slide or background mode. 
The option is marked by default.

OR simply revert.

Is there a way to vote on such things?

No there is no voting. Volunteers fix things when they want to - this is a meritocracy not a democracy :)

(In reply to Joel Madero from comment #26)
> No there is no voting. Volunteers fix things when they want to - this is a
> meritocracy not a democracy :)

I understand, but how do we determine if this particular issue merit change?

Perhaps we should try 'combocracy'.

(In reply to Kumāra from comment #25)
> (In reply to Dennis Van Dusen from comment #24)
> > So, I take the point, but I think the issue will resolve in only one outcome
> > - everyone gets their own 'last edit' pointer, but that pointers storage
> > area might not be in the document for everyone.
> 
> What you're saying here is already true for Writer and Calc. I didn't
> understand why the same wasn't true for Impress until Thorsten mentioned it.
> (Comment 17)

From my point of view of Writer, Calc and Impress user, the main difference between Impress and other modules is that it has the slide sorter which give you a global view on the document and makes very easy to find the slide you want work on. That makes indifferent for me that Impress opens the file at the last modified slide.

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #28)
> From my point of view of Writer, Calc and Impress user, the main difference
> between Impress and other modules is that it has the slide sorter which give
> you a global view on the document and makes very easy to find the slide you
> want work on. That makes indifferent for me that Impress opens the file at
> the last modified slide.

Thanks for joining, Jean.

What you say makes perfect sense (and I've resorted to the sorter too), until perhaps your slides number 140, like mine.

The question is this: Which is more sensible? Having an ODP opened at the first slide or where the user last saved it?

FYI, I also have a long well-structured ODT (98 pages), which I can find where I left off with the Navigator too. But I'm *very* grateful that Writer opens it where I left off instead. I'll be very grateful too if Impress does the same.

Is there any good reason to retain its current status of always opening at the first slide?

(In reply to Kumāra from comment #27)
> (In reply to Joel Madero from comment #26)
> > No there is no voting. Volunteers fix things when they want to - this is a
> > meritocracy not a democracy :)
> 
> I understand, but how do we determine if this particular issue merit change?
> 
> Perhaps we should try 'combocracy'.

http://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/

That gives an explanation of how the community works and why democracy/voting/etc.... is never going to happen.

OK. So be it.

Anyway, I've made my point at Comment 29. Are we still waiting for ux-advise for input?

-- Here is UX Advice -- 

Use of F5 accelerators as currently implemented provide the best UX.

A toolbar or menu button action to call the .uno:RestoreEditingView would not be an unreasonable enhancement. 

Placement on the Standard TB "View", or possibly the "SlideShow" menu would be functional location to provide a button action -- "Return to last edited slide...  Alt+Shift+F5"

But, could also be included a button action during rework of Impress view tabs of bug 87672

Resolving fixed.

=-=-=
Discussion:

LibreOffice Impress is both the editing and the viewing application for ODF Presentations. Simply put, vastly more Presentations will be opened for viewing, than opened for editing. Accordingly, by design as noted in bug 58505--default opening with F5 at the first slide, and <Shift>+F5 opening presentation from the current slide selected, with navigator or from the slide sorter, was implemented as reasonable UX. This corrected OOo inherited action of F5 always opening SlideShow at current slide.

Also, assigning <Shift>+F5 to open slide show to current slide, displacing the long present, but non-functional, use of <Shift>+F5 to reposition edit session to last used position was reasonable UX.

Inherited from OOo Impress Navigator is launched with F5_SHIFT_MOD1 (<Ctrl>+<Shift>+<F5>), that and the slide sorter panel allow GUI navigation to desired slide.  However, also inherited from OOo, is an accelerator assigned to restore edit session of presentation to the last edited slide. However, the F5_SHIFT accelerator (<Shift>+<F5>) was never functional in LibreOffice.

For the 4.1 branch, LibreOffice UX design rework assigned use of F5 and <Shift>+F5 to control SlideShow menu actions.  The non-functional open at last edited slide was reassigned to F5_SHIFT_MOD2 (<Alt>+<Shfit>+F5) accelerator. 

Function of that UNO command was corrected prior to release of 4.2 branch and is correct through current master.

In short--the accelerator exists and functions as designed/intended. The last edit location details are recorded into the ODF .ODP archive and are exposed to the VeiwShell for use during an Impress editing session. The accelerator F5_SHIFT_MOD2 now functions as intended to reposition the edit session to last edited slide. Nothing to be done for this enhancement, resolving fixed.


=-=-=
Background

As Thorsten noted in comment 17, the feature exists and is functional using the UNO command .uno:RestoreEditingView


While code is present in LO, and F5_SHIFT_MOD1 correctly launches Navigator, not clear F5_SHIFT ever worked. Just verified it is inoperable 3.3.0 -> 4.1.6.2

The non-functional command was reassigned from F5_SHIFT accelerator by work (Joren, Kuba, and Samuel) on bug 58505 which defines Slide Show accelerators for Presentation:

F5 - Start from first slide, 
F5_SHIFT - Start from current slide

And creates respectively these Presentation module commands:
.uno:Presentation
.uno:PresentationCurrentSlide

It reassigned .uno:RestoreEditingView to
F5_SHIFT_MOD2 - Restore last editing view

While the reassignment of Presentation module F5 and F5_SHIFT to new UNO commands are functional for 4.1 branch, the uno.RestoreEditingView was not.

The linkage was finally corrected (possibly by Steven B's work on ViewShellBase.cxx) and was fully functional with the F5_SHIFT_MOD2 accelerator for 4.2.0.4 release. It remains so.

REfs

OOo work Assigning Navigator to <Ctrl><Shift><F5>, and creating RestoreEditingView action
https://bz.apache.org/ooo/show_bug.cgi?id=50901

Initial commit for bug 58505
http://cgit.freedesktop.org/libreoffice/core/commit/?id=baffab9a4ffca9a4940a3310937d6e858e66cc1f

additional clean up for bug 58505
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c41dfa1265c6de8045f3a7bfd248ec0f8d9fc8c3

work on ViewShell
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6eb208473109234886600ac299f0cc75ee94e9c

Hey VSF - great write up. Thanks for taking the time.

Side note and not entirely important - shouldn't this be WONTFIX and not FIXED?

@Kumara - please don't reopen the bug - it was discussed at length, a full explanation was given, and UX has decided not to implement the change. Thanks for understanding.

(In reply to Joel Madero from comment #33)
> Side note and not entirely important - shouldn't this be WONTFIX and not
> FIXED?

Nope, issues of the missing/inoperable accelerator were fixed for 4.2.0.4 release and subsequent--Kumāra simply elected not to update.

Unfortunately the Easyhack status for this issue burned through a lot of useful fledgling dev time--thank you none the less, but admittedly not obvious until one digs into the archives.

I've opened enhancement bug 90030 to provide a button action in addition to the F5_SHIFT_MOD2 accelerator.

(In reply to Joel Madero from comment #33)
> @Kumara - please don't reopen the bug - it was discussed at length, a full
> explanation was given, and UX has decided not to implement the change.
> Thanks for understanding.

I'm not completely satisfied, but understand fully and accept the decision. Will not reopen the bug. Thanks for you all for your attention in this, and to VSF for opening the new enhancement bug.

(In reply to Joel Madero from comment #33)
> @Kumara - please don't reopen the bug - it was discussed at length, a full
> explanation was given, and UX has decided not to implement the change.
> Thanks for understanding.

I understand fully and accept the decision. Will not reopen the bug. Thanks for you all for your attention in this, and to VSF for opening the new enhancement bug.

Yikes! Sorry for the repeated submissions. I kept getting error messages, and thought it didn't get through. Sorry, and thanks again.