Description: It is possible for the currently-edited slide not to be visible, or to be at the top or bottom edge, in the set of slides on the "slides" vertical navigation bar. Instead of having to scroll up or down to find the current slide (by its selection indication or its number), it should be possible to easily re-center the slides bar on the current slide (or as close to re-centering as possible when it is one of the first or last few slides). Options I can think of: * A button on the header of the slides bar (which currently only says "Slides" and has an X button for closing it). This would be similar to the "centering" button in CLion/IntelliJ/PyCharm's file hierarchy navigation vertical bar, which re-centers/focuses on the currently-edited source file. * A double-click effect for the slide number indicator on the bottoms status bar * A toolbar button * An item on the slide background's context menu ... and perhaps a combination of the above. Steps to Reproduce: Nothing to reproduce Actual Results: N/A Expected Results: N/A Reproducible: Always User Profile Reset: No Additional Info: Reported with build: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 6c81a09e3ef239a2d7a991d00fe3620a67298b99 CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
I never get the name of this part of the window right... do we call it the slide sorter? The slide pane? The slide side-bar?
(In reply to Eyal Rozenberg from comment #1) +1, the slide/page "Slides/Pages pane" needs a control to scroll the pane to expose the active slide/page with edit focus. Currently, except for the dragging the thumb of the scrollbar, it is much too easy to unintentionally change focus to a different slide/page present in the pane. Providing an UNO action to scroll the pane to expose the Slide/Page with edit focus--for use on keyboard, menu and context menu actions would be very helpful. =-=-= As an aside for documentation: > I never get the name of this part of the window right... do we call it the > slide sorter? The slide pane? The slide side-bar? It is the sd "LEFT PANE", with UNO cmds available to toggle it inactive. In Impress it is uno.leftPaneImpress and menu labeled 'Slide Pane' In Draw it is uno.leftPaneDraw and menu labeled 'Page Pane' But in the Impress UI it is labeled 'Slides', and in Draw UI it is labeled 'Pages' Functionally the sd Left Pane, aka "Slides pane" or "Pages pane" in the module guides documentation, can be used to manage slides/pages, e.g. add, duplicate, hide, delete, move for the listed slide/page objects. The Left Pane is incorrectly referred to as the 'Slide Sorter'. That labeling is for a specific editing "view mode" of the Impress workspace--not available in Draw. And the LO help even has the toggle article named "slidesorter.html" adding to the confusion, and that all could probably be clarified. @Olvier, Seth?
Do we talk about what slide is the currently active - which is clearly shown in the slides bar by highlighting - or about the slider canvas that you can center with View > Zoom > Entire Page. Don't see need for more interactive controls.
(In reply to Heiko Tietze from comment #3) The Slides pane, obviously. Issue is that an imprecise click-hold of the scrollbar thumb can too easily change selection of the active slide in Impress (or page in Draw). For Presentations (or Drawings) with more than a few slides it can be very disruptive to have to reidentify and position to the slide (or drawing page) you were working on. This additional UNO control to re-center the pane without risk of bumping the focus onto another slide would be useful assigned to a menu, a context menu or a keyboard shortcut.
(In reply to V Stuart Foote from comment #4) > Issue is that an imprecise click-hold of the scrollbar thumb can too easily > change selection of the active slide in Impress (or page in Draw). Like in any other list. With the difference that the slide/page is large and clearly highlighted. -1 from my side.
I also understood that View > Zoom > Entire Page is what's described here. Let's close. Note bug 38164.
NO it is strictly a feature request for the Slide / Page pane -- which technically is a list as Heiko notes. Nothing at all to do with Zoom of the currently active slide/page! Read the description, and its blocking of bug 102283 The request is for a means to control the list of slides/pages to position the list view to the active slide/page without risk of changing onto a different slide.
(In reply to V Stuart Foote from comment #7) > NO it is strictly a feature request for the Slide / Page pane -- which > technically is a list as Heiko notes. Stuart is exactly right. (In reply to Heiko Tietze from comment #3) > Do we talk about what slide is the currently active - which is clearly shown > in the slides bar by highlighting Ah, but it isn't always. That is, the currently active slide is only shown in the slides bar if its scroll position is close enough to the slide's position.
You can use the tab key to refocus the list.
(In reply to Heiko Tietze from comment #9) > You can use the tab key to refocus the list. I can also use the mouse to refocus the list, but that's the problem... I want to change the position on the list without carefully scrolling to the right position.
(In reply to Eyal Rozenberg from comment #10) > I want to change the position on the list without carefully scrolling to the > right position. Why not (also) scroll to the beginning/end of the list, some "favorite" slide/page, jump to a slide/page by name, sort by size... hope you get my point. The list is simple, efficient, and familiar in use. Adding complexity is detrimental to usability.
(In reply to Eyal Rozenberg from comment #10) > (In reply to Heiko Tietze from comment #9) > > You can use the tab key to refocus the list. > > I can also use the mouse to refocus the list, but that's the problem... I > want to change the position on the list without carefully scrolling to the > right position. Tab key focuses to the slide in use, without scrolling, if mouse is in Slide Pane. It seems to fit the need explained here. But it may not be obvious for a user. Heiko, please mark NotABug with that explanation or confirm with some of the proposals. A double-click on the status bar slide number indicator seems fine for me.
(In reply to Timur from comment #12) > Heiko, please mark NotABug with that explanation or confirm with some of the > proposals. Will do but my opinion is just one drop of water in the ocean.
(In reply to Timur from comment #12) > (In reply to Eyal Rozenberg from comment #10) > > (In reply to Heiko Tietze from comment #9) > > > You can use the tab key to refocus the list. > > > > I can also use the mouse to refocus the list, but that's the problem... I > > want to change the position on the list without carefully scrolling to the > > right position. > > Tab key focuses to the slide in use, without scrolling, if mouse is in Slide > Pane. > It seems to fit the need explained here. > But it may not be obvious for a user. > No, on Windows at least, returning focus to the Slide pane the <TAB> does not reposition the view to show active--and doing the refocus risks bumping the active slide/page as noted. A deficiency given that the <Home>, <End> and cursors <U,D /PgUp,PgDn> will re-position the Slide with focus into the pane. What is missing is an ability to first focus into the Slide pane, and then to reposition the slide list without bumping it off the slide with active edit focus.
While the highlighting should be sufficient for identifying the currently active slide it has apparently some bugs as reported in bug 90652 (not confirming myself) and bug 92254 (confirming). Bug 78848 requests a focus where the slide before and after is shown. And bug 100876 is about accessibility. The meta ticket probably holds more relevant information.
(In reply to V Stuart Foote from comment #2) > The Left Pane is incorrectly referred to as the 'Slide Sorter'. That > labeling is for a specific editing "view mode" of the Impress workspace--not > available in Draw. > > And the LO help even has the toggle article named "slidesorter.html" adding > to the confusion, and that all could probably be clarified. @Olvier, Seth? It seems like you want to file a separate bug about this point?
(In reply to Eyal Rozenberg from comment #16) > (In reply to V Stuart Foote from comment #2) > > The Left Pane is incorrectly referred to as the 'Slide Sorter'. That > > labeling is for a specific editing "view mode" of the Impress workspace--not > > available in Draw. > > > > And the LO help even has the toggle article named "slidesorter.html" adding > > to the confusion, and that all could probably be clarified. @Olvier, Seth? > > It seems like you want to file a separate bug about this point? Sure, done as bug 151347
We discussed the topic in the design meeting. Usually there are some indicators of the currently active slide. First of all, the thumbnail is highlighted but we also show the "Page n of m" information in the left-most panel of the statusbar. The proposed UNO command extends the UNO API unnecessarily, and pressing some key combinations would be quite unusual anyway. Adding a button to the slide panel, for example next to the close button (x), has an acceptable low impact on the UI. But the issue actually happens when the slide loses focus, eg. by clicking white space in the slide sorter. Then both information are gone (the slide pane highlighting is still okay on Windows and Linux/kf5 with a clear blue frame). So what we should do is to a) always show the statusbar information what slide is active, and b) have no white space in the slide panel. Recommendation is to change the summary into "Keep active slide in focus". (Leaving status unconfirmed for the current "re-center the list" request that is rather WF.)
(In reply to Heiko Tietze from comment #18) > We discussed the topic in the design meeting. I'm sorry I couldn't attend the meeting. By the way, who participated > Usually there are some indicators of the currently active slide. First of > all, the thumbnail is highlighted The thumbnail is not highlighted if the current slide is not part of the visible set of slides on the slide page - which is the scenario for which this bug was filed. > but we also show the "Page n of m" information in the left-most panel of the statusbar. Indeed, it is possible to do some mental work, estimate the position of the slider on the scroll bar, divide N by M, and conclude whether you should scroll up or down, with a good chance of being correct. But that really is too much work, not to mention you need to scroll up by just the right amount, which, in a long slideshow is itself a bit of effort. > The proposed UNO command I did not propose an UNO command, so that's kind of a straw man. >extends the UNO API unnecessarily, and pressing > some key combinations would be quite unusual anyway. Adding a button to the > slide panel, for example next to the close button (x), has an acceptable low > impact on the UI. ... and that's what I'm asking for. There's empty screen real-estate for it as well. > But the issue actually happens when the slide loses focus, eg. by clicking > white space in the slide sorter. Then both information are gone (the slide > pane highlighting is still okay on Windows and Linux/kf5 with a clear blue > frame). No. That is, yes, if the slide also loses focus, then things are even worse, but I filed this issue even for when the slide _is_ focused on the pane - it's just that the slide may be focused, but not in view. > So what we should do is to a) always show the statusbar information what > slide is active, and b) have no white space in the slide panel. I don't know about that, and it's certainly not what I'm asking for with this issue. Please open a separate issue for avoiding loss of focus for the current slide - but it's not the problem here. > Recommendation is to change the summary into "Keep active slide in focus". Again, separate bug. > (Leaving status unconfirmed for the current "re-center the list" request > that is rather WF.) I don't believe you could seriously argue that doing integer division for estimating scrolling extents is something that "works for you".
Don't forget the fact that editing focuses the current slide.
(In reply to Heiko Tietze from comment #20) > Don't forget the fact that editing focuses the current slide. I'm not forgetting that - remember, I filed this bug thinking about slides which are already focused. Maybe I should also mention that another possibility for resolving this is scrolling to the current slide automatically when you start editing it. I'm not sure if I like that better than the solution I already suggested, but perhaps this should also be considered. i.e. is it useful enough to be able to edit a slide while only seeing other slides in the slides pane.
(In reply to Eyal Rozenberg from comment #21) > Maybe I should also mention that another possibility for resolving this is > scrolling to the current slide automatically when you start editing it. Which is a fact for me with the current version.
(In reply to Heiko Tietze from comment #22) > (In reply to Eyal Rozenberg from comment #21) > > Maybe I should also mention that another possibility for resolving this is > > scrolling to the current slide automatically when you start editing it. > > Which is a fact for me with the current version. That's not what happens with: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: bb67f10786fd5e232b198d09139c41078c3fc60d CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Are you sure we're talking about the same thing? Scrolling, not focus?
(In reply to Heiko Tietze from comment #22) > (In reply to Eyal Rozenberg from comment #21) > > Maybe I should also mention that another possibility for resolving this is > > scrolling to the current slide automatically when you start editing it. > > Which is a fact for me with the current version. Important detail: for this to happen, the slide needs to be *unfocused* in the Slides pane. So first click in the whitespace in the pane.
(In reply to Eyal Rozenberg from comment #23) > That's not what happens with: True, not working under kf5 too. Tested with Windows and maybe it's working there. But the point is that we could just focus the currently active slide in the slide pane on any editing action. If this is working for some OS/DE - fine.
(In reply to Buovjaga from comment #24) > Important detail: for this to happen, the slide needs to be *unfocused* in > the Slides pane. So first click in the whitespace in the pane. Ah, now I get it. Well if that's the behavior in case of unfocused, you could also decide that the same thing happens when the slide is focused, so that scrolling away from it can only happen while it's not being edited. That will resolve this bug, improve consistency and not add any UI. However - it would mean cancelling the behavior we have now, which, in theory, could ruffle some feathers: https://xkcd.com/1172/